From sami.badri at gmail.com Sat Jan 1 03:18:12 2022 From: sami.badri at gmail.com (S.B.) Date: Fri, 31 Dec 2021 21:18:12 -0500 Subject: detached signature, "can't hash datafile: No data" Message-ID: Hello, I wanted to verify an install file so I downloaded file.dmg and the accompanying detached signature.asc. The public key was imported and verified. Using GnuPG, I used the command: gpg --verify signature.asc file.dmg and.. "Good signature from..." However, when I try to verify signature.asc independently using the command: gpg --verify signature.asc it states: gpg: no signed data gpg: can't hash datafile: No data Shouldn't I be able to verify the signature independently? S.B. From rjh at sixdemonbag.org Sat Jan 1 05:12:16 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 31 Dec 2021 23:12:16 -0500 Subject: detached signature, "can't hash datafile: No data" In-Reply-To: References: Message-ID: <81ca10b8-96ca-4564-6317-827b8ee857d8@sixdemonbag.org> > Shouldn't I be able to verify the signature independently? Why? A signature is a piece of data that attests another piece of data is unchanged. If it doesn't have a second piece of data to compare to, all it can say is "I have a good digital signature that attests to a hash value of XYZ for some piece of data, but, uh ... where's the data?" Detached signatures (clearsign signatures being one kind of them) do not include the original data. You can sign gigabytes of data and the detached signature will still be only a few hundred bytes in size, because the original data isn't there. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x1DCBDC01B44427C7.asc Type: application/pgp-keys Size: 11861 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From sami.badri at gmail.com Sat Jan 1 20:01:52 2022 From: sami.badri at gmail.com (Sami Badri) Date: Sat, 1 Jan 2022 14:01:52 -0500 Subject: detached signature, "can't hash datafile: No data" In-Reply-To: <81ca10b8-96ca-4564-6317-827b8ee857d8@sixdemonbag.org> References: <81ca10b8-96ca-4564-6317-827b8ee857d8@sixdemonbag.org> Message-ID: <15ed2299-1369-33b5-fc0a-2bde11e4f0ad@gmail.com> On 12/31/21 23:12, Robert J. Hansen via Gnupg-users wrote: >> Shouldn't I be able to verify the signature independently? > > Why? > > A signature is a piece of data that attests another piece of data is > unchanged.? If it doesn't have a second piece of data to compare to, > all it can say is "I have a good digital signature that attests to a > hash value of XYZ for some piece of data, but, uh ... where's the data?" > Makes sense.? I see my mistake.? I was practicing on my own created signatures on my own files.? So I was able to verify my own .sig because.. gpg: assuming signed data in '/Users/samibadri/desktop/cryptcommands.txt' gpg: Signature made Sat Jan? 1 13:06:36 2022 EST gpg:??????????????? using RSA key 5CD9A3BC1577A0FDB8B11CD02DE90FECE5438DA0 gpg: Good signature from "SamiB (pgp key pair #1) " [ultimate] > Detached signatures (clearsign signatures being one kind of them) do > not include the original data.? You can sign gigabytes of data and the > detached signature will still be only a few hundred bytes in size, > because the original data isn't there. > I would've thought that a clearsign signature preserves the data above the pgp signature, in plaintext.? Isn't the plaintext above the signature the original data? S.B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sat Jan 1 20:02:26 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 1 Jan 2022 14:02:26 -0500 Subject: detached signature, "can't hash datafile: No data" In-Reply-To: <15ed2299-1369-33b5-fc0a-2bde11e4f0ad@gmail.com> References: <81ca10b8-96ca-4564-6317-827b8ee857d8@sixdemonbag.org> <15ed2299-1369-33b5-fc0a-2bde11e4f0ad@gmail.com> Message-ID: <8da55770-74b9-afa6-4916-d9fe1375279a@sixdemonbag.org> > I would've thought that a clearsign signature preserves the data above the pgp signature, in plaintext. Isn't the plaintext above the signature the original data? In that case, it is. I spoke inartfully: I meant to say that detached signatures can be done in either a binary format or in ASCII-printable. From christoph-klassen at mail.de Sun Jan 2 14:39:13 2022 From: christoph-klassen at mail.de (Christoph Klassen) Date: Sun, 2 Jan 2022 14:39:13 +0100 Subject: Levels of validation Message-ID: <4907b6d8-6946-0c41-5cd3-b3426673a3a0@mail.de> Hello, in the GNU Privacy Handbook there are mentioned two levels of trust and validation: marginal and full (https://www.gnupg.org/gph/en/manual.html#AEN335). Is this information still correct? Because, when I edit the trust of a key, I can select both if these options, but can also decide to trust a key ultimately. That's why I was wondering, if there are still only the two levels and if the conditions for a valid key are still the same. Greetings, Christoph From klaus+gnupg at ethgen.ch Sun Jan 2 15:05:03 2022 From: klaus+gnupg at ethgen.ch (Klaus Ethgen) Date: Sun, 2 Jan 2022 15:05:03 +0100 Subject: Levels of validation In-Reply-To: <4907b6d8-6946-0c41-5cd3-b3426673a3a0@mail.de> References: <4907b6d8-6946-0c41-5cd3-b3426673a3a0@mail.de> Message-ID: Hi Christoph, Am So den 2. Jan 2022 um 14:39 schrieb Christoph Klassen via Gnupg-users: > in the GNU Privacy Handbook there are mentioned two levels of trust and > validation: marginal and full > (https://www.gnupg.org/gph/en/manual.html#AEN335). Is this information still > correct? Yes. But depends on your trust-model setting (see man page). > Because, when I edit the trust of a key, I can select both if these > options, but can also decide to trust a key ultimately. That's why I was > wondering, if there are still only the two levels and if the conditions for > a valid key are still the same. The trust "ultimative" should only set to your very own keys! You never use that setting for anything else. The trust "full" is for keys that are fully trusted, either by you having signed it with an ultimative trusted key or depending on the trust model by signed from multiple other trusted keys or by TOFU... The trust "marginal" is for keys that got not enough trust to be fully trusted. Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 688 bytes Desc: not available URL: From christoph-klassen at mail.de Sun Jan 2 16:45:47 2022 From: christoph-klassen at mail.de (Christoph Klassen) Date: Sun, 2 Jan 2022 16:45:47 +0100 Subject: Levels of validation In-Reply-To: References: <4907b6d8-6946-0c41-5cd3-b3426673a3a0@mail.de> Message-ID: <2d47fdde-2c8b-6b6b-75d4-31dca0285cb7@mail.de> Hello Klaus, On 02.01.22 15:05, Klaus Ethgen wrote: > Yes. But depends on your trust-model setting (see man page). Okay, I will read it. Sounds interesting because developers could decide to display the level of validation in their application, but if users change the settings, this could stop working. > The trust "ultimative" should only set to your very own keys! You > never use that setting for anything else. I already thought that I shouldn't do this. But, wouldn't it be the same as when I sign a key? In the end both ways show that I trust the key and if I sign a key I do trust it ultimately. Greetings, Christoph From kloecker at kde.org Sun Jan 2 19:45:27 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 02 Jan 2022 19:45:27 +0100 Subject: Levels of validation In-Reply-To: <2d47fdde-2c8b-6b6b-75d4-31dca0285cb7@mail.de> References: <4907b6d8-6946-0c41-5cd3-b3426673a3a0@mail.de> <2d47fdde-2c8b-6b6b-75d4-31dca0285cb7@mail.de> Message-ID: <5476799.P0kxoMyt9x@breq> On Sonntag, 2. Januar 2022 16:45:47 CET Christoph Klassen via Gnupg-users wrote: > On 02.01.22 15:05, Klaus Ethgen wrote: > > Yes. But depends on your trust-model setting (see man page). > > Okay, I will read it. Sounds interesting because developers could decide > to display the level of validation in their application, but if users > change the settings, this could stop working. Developers should always use gpg (e.g. via gpgme) to calculate the level of validation. > > The trust "ultimative" should only set to your very own keys! You > > never use that setting for anything else. > > I already thought that I shouldn't do this. But, wouldn't it be the same > as when I sign a key? In the end both ways show that I trust the key and > if I sign a key I do trust it ultimately. Please be very careful to differentiate between owner trust and (level of) validity. Unfortunately, very often people shorten both to "trust". First, you don't trust keys similarly as you don't trust id cards. You trust (or don't trust) the "owner" of a key that they are doing a proper job when they sign other keys similarly as you trust or don't trust the issuers of id cards that they are doing a proper job when they certify the identity of the id card holder. Now let's look at your above statement. > But, wouldn't it be the same > as when I sign a key? In the end both ways show that I trust the key and > if I sign a key I do trust it ultimately. No, it wouldn't be the same. Let's assume you have only two keys A and B in your key ring that are not your own keys. Let's further assume that key B is signed with key A. (And let's assume the default trust model is used by gpg.) If you sign key A, then key A will be considered valid by gpg but key B will not be considered valid by gpg (unless you also signed key B). If you set the owner trust of key A to "ultimate", then key A will be considered valid by gpg (because ultimate owner trust implies full validity) and key B will also be considered valid by gpg (because it has been signed with a key whose owner you assigned ultimate trust). Now, if you sign key A and set the owner trust of key A to "full", then key A and key B will be considered valid by gpg. With regard to the validity of the two keys A and B the result of the last two cases are the same. But the semantics of key signatures and owner trust are completely different. You can share key signatures with other people (by exporting the public key including your signatures), but you usually don't share the owner trust you have assigned to keys with other people. The reason is simple: People may trust you to do a proper job certifying keys you sign (e.g. by verifying the identity of the owners of keys), so that they may tell their gpg to trust your signatures. But people will most likely have a very different idea about whom they trust. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From x10an14 at gmail.com Mon Jan 3 00:19:48 2022 From: x10an14 at gmail.com (Christian Chavez) Date: Mon, 3 Jan 2022 00:19:48 +0100 Subject: Is it possible to require two private keys to decrypt with gpg? In-Reply-To: <1c220638a9f36cc707fe59085a4adc6499b26709.camel@16bits.net> References: <1c220638a9f36cc707fe59085a4adc6499b26709.camel@16bits.net> Message-ID: On Sun, Jan 2, 2022 at 11:01 PM ?ngel wrote: > You could use a wrapper which calls gpg twice, while the user only > calls your wrapper (as if it is gpg) once. > Thank you, I think that sounds like the best solution I've come across so far! =) > However, I would like to question your need for requiring two gpg keys. > How are they two gpg going to be more secure? Usually, if someone was > able to steal one key, they could steal the second one as well as the > same time, and you could simply require a different second key, or > tweak the key parameters to get an higher level, if that's what you > want to achieve from the double encryption. > False assumption here =) One key is on me at all times, and also on a (physically and OS-wise) locked air-gapped machine. The other one is in a safe. So I question the assumption that "if someone was able to steal one key, they could steal the second as well" - considering that at least one of them goes with me wherever I go, including work and vacation. (The safe e.g. doesn't^^) -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chd at chud.net Sun Jan 2 23:23:08 2022 From: chd at chud.net (Chris DeYoung) Date: Sun, 2 Jan 2022 15:23:08 -0700 Subject: Is it possible to require two private keys to decrypt with gpg? In-Reply-To: <1c220638a9f36cc707fe59085a4adc6499b26709.camel@16bits.net> References: <1c220638a9f36cc707fe59085a4adc6499b26709.camel@16bits.net> Message-ID: > However, I would like to question your need for requiring two gpg keys. > How are they two gpg going to be more secure? Guessing that possibly two different people need to be in agreement in order to access data, along the lines of needing two keys to launch missiles? :) Otherwise, I agree just encrypting twice doesn't seem to buy much. -C From wk at gnupg.org Mon Jan 3 08:19:26 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Jan 2022 08:19:26 +0100 Subject: [Announce] A New Future for GnuPG Message-ID: <871r1p1e2p.fsf@wheatstone.g10code.de> Hello and a Happy Gnu Year! It has been quite some time since my last status report on GnuPG. I have been quite busy working on the project but unfortunately rarely active on the usual channels. So, here is a new report telling what we did over the last two or three years. Please read at least the last section. A web version of this article is available at https://gnupg.org/blog/20220102-a-new-future-for-gnupg.html Some background =============== In the beginning GnuPG was a fun project I did in my spare time. After a few years this turned out to be a full time job and it was possible to acquire paid projects to maintain and further develop GnuPG. When the BSI (Germany's Federal Office for Information Security) migrated back from Linux to Windows, a need to migrate their end-to-end encryption solution, based on GnuPG and KMail, was needed. A call for bids for an Open Source solution was issued and our company, g10 Code, along with our friends at Intevation and KDAB received the contract. The outcome was Gpg4win, the meanwhile standard distribution of GnuPG for Windows. It turned out that the software used in Germany to protect restricted data at the VS-NfD level, called Chiasmus, showed its age. For example, the block length of 64 bits (like IDEA or 3DES) is not anymore secure for data of more than 150 MiB. Also the secret encryption algorithm has not anymore the confidence people used to have in it and due to lacking hardware support it is quite slow. A new call to bid for a replacement of that software was issued and we also with Intevation were granted the contract. Our solution was to update GnuPG and its frontends Kleopatra and GpgOL. After some thorough evaluation of our software (working title /Gpg4VS-NfD/) and the usual bureaucratic we received a first approval in January 2019. Meet GnuPG.com ============== I have been working with Andre Heinecke of Intevation GmbH since about 2010 on Gpg4win and some other projects. With the foreseeable approval of /Gpg4VS-NfD/ Andre then left Intevation and took over 40% of the g10 Code shares from my brother (I am holding the other 60%). We started to make a real product out of /Gpg4VS-NfD/. Thus we rented a new office to work desk by desk on this and hired staff for sales and marketing. We introduced the brand /GnuPG.com/ to have a better recognition of our product than by our legal name /g10 Code GmbH/. The software itself was re-branded as /GnuPG VS-Desktop?/ and distributed as an MSI packet for Windows and as an AppImage for Linux. Except for customer specific configuration files /GnuPG VS-Desktop/ is and will always be Open Source under the GNU General Public License. We also keep maintaining /Gpg4win/ as the community version. This is based on the the same source code as /GnuPG VS-Desktop/ but comes with more features due to the use of the latest development branch. The benefits for the customer to pay for /GnuPG VS-Desktop/ are: a commercial support contract, the guarantee of a long term maintained and approved version, customization options, community tested new features, and the per-approval required vendor for security updates. Also technically published for longer, it became only last year widely known, that the legacy Chiasmus software may not anymore be used for restricted communication from this year on. For the administration and also for the industry two option exist to migrate away from Chiasmus: the proprietary GreenBone software from /cryptovision GmbH/ and our Open Source software /GnuPG VS-Desktop/. The rush towards GnuPG VS-Desktop ================================= Since summer 2021 the phones of our sales team didn't stop ringing and we could bring in the fruits of our work. We were not aware how many different governmental agencies exist and how many of them have a need to protect data at the VS-NfD (restricted) level. And with those agencies also comes a huge private and corporate sector who also have to handle such communication. Although we support S/MIME, the majority of our customers decided in favor of the OpenPGP protocol, due to its higher flexibility and independence of a centralized public key infrastructure. A minor drawback is that for a quick start and easy migration from Chiasmus, many sites will use symmetric-only encryption (i.e. based on "gpg -c"). However, the now deployed software provides the foundation to move on to a comfortable public-key solution. In particular, our now smooth integration into Active Directory makes working with OpenPGP under Windows really nice. We were also able to partner with Rohde & Schwarz Cybersecurity GmbH for a smooth integration of GnuPG VS-Desktop with their smartcard administration system. We estimate that a quarter million workplaces will be equipped with GnuPG VS-Desktop and provide the users state of the art file and mail encryption. Our longer term plan is to equip all public agency workplaces with end-to-end encryption software - not only those with an immediate need for an approved VS-NfD solution. This should also fit well into the announced goal of the new German government to foster the development of Open Source. Kudos to all supporters ======================= For many years our work was mainly financed by donations and smaller projects. Now we have reached a point where we can benefit from a continuous revenue stream to maintain and extend the software without asking for donations or grants. This is quite a new experience to us and I am actually a bit proud to lead one of the few self-sustaining free software projects who had not to sacrifice the goals of the movement. Those of you with SEPA donations, please cancel them and redirect your funds to other projects which are more in need of financial support. The Paypal and Stripe based recurring donations have already been canceled by us. All you supporters greatly helped us to keep GnuPG alive and to finally setup a sustainable development model. *Thank you!* Salam-Shalom, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- g10 Code GmbH -=- GnuPG.com -=- AmtsGer. Wuppertal HRB 14459 Bergstr. 3a Gesch?ftsf?hrung Werner Koch D-40699 Erkrath https://gnupg.com USt-Id DE215605608 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Mon Jan 3 09:23:07 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Jan 2022 09:23:07 +0100 Subject: [Announce] A New Future for GnuPG In-Reply-To: <871r1p1e2p.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-users's message of "Mon, 03 Jan 2022 08:19:26 +0100") References: <871r1p1e2p.fsf@wheatstone.g10code.de> Message-ID: <87tuelz0r8.fsf@wheatstone.g10code.de> Hi! small but important correction: > Chiasmus: the proprietary GreenBone software from /cryptovision GmbH/ Of course I meant GreenShield and not Greenbone. The latter is a company which provides free software network security scanners. See https://www.greenbone.net/en/ 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 rjh at sixdemonbag.org Mon Jan 3 17:31:32 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 3 Jan 2022 11:31:32 -0500 Subject: [Announce] A New Future for GnuPG In-Reply-To: <871r1p1e2p.fsf@wheatstone.g10code.de> References: <871r1p1e2p.fsf@wheatstone.g10code.de> Message-ID: Werner, this is amazing news. Thank you for sharing it! For the list: as you may remember, each Christmas I run a fundraiser for GnuPG. You pledge $X and I match it, that sort of thing. I didn't do one this year because Werner contacted me earlier asking me not to, saying he would soon have news that would put GnuPG on much more solid financial footing. I'm happy the news is finally ready for sharing. :) I first started using GnuPG in '99, when I was twenty-four years old and hired by a major telecommunications firm to secure their billing back-end. Although the full scope of that project isn't relevant here, I did spend about six months doing a clean-room implementation of RFC2440 in PHP3. It was a vile experience and one I don't recommend. But GnuPG was about to hit 1.0, and I leaned on the 0.99 and 1.0 code very heavily to make sense of the RFC2440 spec. I continued to use it throughout the years since, and once the NDA with the telecommunications firm expired joined the mailing list. I've been here ever since. I hope to be here for some years to come. It's been a pretty good 23 years so far! -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon Jan 3 18:18:52 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 03 Jan 2022 17:18:52 +0000 Subject: [Announce] A New Future for GnuPG In-Reply-To: References: <871r1p1e2p.fsf@wheatstone.g10code.de> Message-ID: On Mon, 2022-01-03 at 11:31 -0500, Robert J. Hansen via Gnupg-users wrote: > Werner, this is amazing news. Thank you for sharing it! Indeed, many congratulations! > I did spend about six months doing a clean-room implementation of > RFC2440 in PHP3.? It was a vile experience and one I don't recommend. I am simultaneously shocked, impressed, and disgusted. ;-) A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: This is a digitally signed message part URL: From andrewg at andrewg.com Mon Jan 3 18:22:33 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 03 Jan 2022 17:22:33 +0000 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: Message-ID: On Fri, 2021-12-31 at 23:23 +0200, Alex Nadtoka wrote: > Ok, thanks. Where on the client end i can remove it? This blog appears to do it correctly (to the best of my knowledge) and as its worked example uses the very same CA certificate that we have just been discussing: ? https://www.thesslstore.com/blog/how-to-remove-certificates-from-windows-10/ A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: This is a digitally signed message part URL: From rjh at sixdemonbag.org Mon Jan 3 18:25:36 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 3 Jan 2022 12:25:36 -0500 Subject: [Announce] A New Future for GnuPG In-Reply-To: References: <871r1p1e2p.fsf@wheatstone.g10code.de> Message-ID: <87078a18-08b7-a181-3089-8f282ed767c6@sixdemonbag.org> >> I did spend about six months doing a clean-room implementation of >> RFC2440 in PHP3.? It was a vile experience and one I don't recommend. > > I am simultaneously shocked, impressed, and disgusted. ;-) I rarely talk about that job because it's sort of like saying you made a healthy and tasty meal out of raw sewage. Even if it's true, you still, uh... yeah. Let's just say that although few people could do it, those of us who have actually done it are filled with shame at our 'accomplishment'. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jrf at mailbox.org Mon Jan 3 19:16:29 2022 From: jrf at mailbox.org (Rainer Fiebig) Date: Mon, 3 Jan 2022 19:16:29 +0100 Subject: [Announce] A New Future for GnuPG In-Reply-To: <871r1p1e2p.fsf@wheatstone.g10code.de> References: <871r1p1e2p.fsf@wheatstone.g10code.de> Message-ID: Great! This sounds like a success story that has only just begun. The right solution at the right time! The market for secure communication is huge and IMO still in its infancy. And for a small fish in a big pond there's lots of room to grow. ;) Congratulations! And good luck to you and GnuPG.com! Rainer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From christoph-klassen at mail.de Mon Jan 3 19:31:42 2022 From: christoph-klassen at mail.de (Christoph Klassen) Date: Mon, 3 Jan 2022 19:31:42 +0100 Subject: Levels of validation In-Reply-To: <5476799.P0kxoMyt9x@breq> References: <4907b6d8-6946-0c41-5cd3-b3426673a3a0@mail.de> <2d47fdde-2c8b-6b6b-75d4-31dca0285cb7@mail.de> <5476799.P0kxoMyt9x@breq> Message-ID: <20220103193142.78e69af9@106431> On Sun, 02 Jan 2022 19:45:27 +0100 Ingo Kl?cker wrote: > With regard to the validity of the two keys A and B the result of the > last two cases are the same. But the semantics of key signatures and > owner trust are completely different. Sorry, I didn't say clear enough what I meant. For me personally it wouldn't make any difference, if I sign a key or trust it (or better: the owner) ultimately. In the end both keys are valid. And for others there would also be no difference, if I would sign a key only locally. Only if I sign a key and upload it, it would make a difference because the owner trust only affects the keys in my keyring, but the signed key affects the validation, if other people own it. Back to the question: > > But, wouldn't it be the same > > as when I sign a key? In the end both ways show that I trust the > > key and if I sign a key I do trust it ultimately. Practically it depends on if I upload the key. If I don't upload it, it wouldn't make any difference. But, as you said, the semantics are different. From steffen at sdaoden.eu Mon Jan 3 18:20:17 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 03 Jan 2022 18:20:17 +0100 Subject: [Announce] A New Future for GnuPG In-Reply-To: References: <871r1p1e2p.fsf@wheatstone.g10code.de> Message-ID: <20220103172017._5PqJ%steffen@sdaoden.eu> Robert J. Hansen wrote in : |Werner, this is amazing news. Thank you for sharing it! | |For the list: as you may remember, each Christmas I run a fundraiser for |GnuPG. You pledge $X and I match it, that sort of thing. I didn't do |one this year because Werner contacted me earlier asking me not to, |saying he would soon have news that would put GnuPG on much more solid |financial footing. I'm happy the news is finally ready for sharing. :) Congratulations also from me. It is nothing but a shame that major projects that are used by billion dollar companies or state agencies have to struggle for "peanuts" (a famous term in Germany since about hm 25 years), whereas commercial shit products shall this term be allowed here generate unbelievable value. ('Assuming that state has not changed also in the software industry, which i bet on.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From gnupg at raf.org Tue Jan 4 06:02:21 2022 From: gnupg at raf.org (raf) Date: Tue, 4 Jan 2022 16:02:21 +1100 Subject: [Announce] A New Future for GnuPG In-Reply-To: <871r1p1e2p.fsf@wheatstone.g10code.de> References: <871r1p1e2p.fsf@wheatstone.g10code.de> Message-ID: On Mon, Jan 03, 2022 at 08:19:26AM +0100, Werner Koch via Gnupg-users wrote: > Hello and a Happy Gnu Year! Happy Gnu Year indeed! Congratulations on the marvellous news, and many thanks for all that you do. cheers, raf From michael.uplawski at uplawski.eu Tue Jan 4 06:54:56 2022 From: michael.uplawski at uplawski.eu (Michael Uplawski) Date: Tue, 4 Jan 2022 06:54:56 +0100 Subject: [Announce] A New Future for GnuPG In-Reply-To: References: <871r1p1e2p.fsf@wheatstone.g10code.de> Message-ID: Am Tue, Jan 04, 2022 at 04:02:21PM +1100 schrieb raf via Gnupg-users: > > Hello and a Happy Gnu Year! This makes me count the years. Should I really start? I had ?used? PGP before I had an Internet-connection and longer even before I had changed careers to become a ?software-developer? (of a kind). In the meantime, I have stopped being the latter and am falling foul of the Net. GnuPG is still a constant in my daily life. Do not be too impressed with the numbers, but if it makes you chuckle, I did something useful this morning. ;) I cannot estimate what you did and have never understood much, but you did it looks as if you did it the right way. Sit back, fold your hands on your belly and smile. And Cheerio ! Michael. -- Je ne r?ponds que avec retard aux messages non-sign?s ou non-chiffr?s (en absence du ?Content-Type: signed? ou ?encrypted?. Messages publics (listes etc.) sont exempt?s de cette r?gle : http://www.uplawski.eu/div/mailblock GnuPG rsa4096 2020-09-08 [SC] [expire : 2022-09-08] B31591374C4824DE872841D27D857E5045D038F8 sub rsa4096 2020-09-08 [E] [expire : 2022-09-08] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alex.nadtoka at gmail.com Tue Jan 4 13:14:47 2022 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Tue, 4 Jan 2022 14:14:47 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: Message-ID: yes thanks, tried disabling it but error was still there. So I deleted DST Root CA X3 . At the mooment I see error from dirmngr 2.3.4: no CA certificate found And error searching keyserver: "No inquire callback in IPC" Not sure if it is still because of root certificate. Will try to google now ??, 3 ???. 2022 ?. ? 19:23 Andrew Gallagher via Gnupg-users < gnupg-users at gnupg.org> ????: > On Fri, 2021-12-31 at 23:23 +0200, Alex Nadtoka wrote: > > Ok, thanks. Where on the client end i can remove it? > > This blog appears to do it correctly (to the best of my knowledge) and > as its worked example uses the very same CA certificate that we have > just been discussing: > > > https://www.thesslstore.com/blog/how-to-remove-certificates-from-windows-10/ > > A > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayapatirr at ncs.com.sg Tue Jan 4 04:17:57 2022 From: rayapatirr at ncs.com.sg (Rayapati Rama Rao (NCS)) Date: Tue, 4 Jan 2022 03:17:57 +0000 Subject: Install gnupg on Linux machine ( For gpg encryption & decryption ) Message-ID: Hi Team, Good Morning! Could you please let me know which gnupg software to download for Linux machine to make use of gpg encryption & decryption. Also, may I know if any packages required to install on Linux prior to gnupg installation. If possible could you please provide me the steps to install gnupg on Linux machine. Thanks in advance, have a wonderful day. Thanks & Regards, RamaRao Rayapati -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph-klassen at mail.de Tue Jan 4 13:34:53 2022 From: christoph-klassen at mail.de (Christoph Klassen) Date: Tue, 4 Jan 2022 13:34:53 +0100 Subject: Install gnupg on Linux machine ( For gpg encryption & decryption ) In-Reply-To: References: Message-ID: <1004a8c9-355d-cf1d-c045-cff8e1020c04@mail.de> Hello Rama Rao, On 04.01.22 04:17, Rayapati Rama Rao (NCS) wrote: > > Could you please let me know which gnupg software to download for > Linux machine to make use of *gpg encryption & decryption.* > > Also, may I know if any packages required to install on Linux prior to > *gnupg* installation. > > If possible could you please provide me the steps to install *gnupg* > on Linux machine. > > Thanks in advance, have a wonderful day. > Which Linux distro are you using? The simplest way would be to install it from the repositories. For example on Debian or a Debian-based distro: "apt install gpg". There is a great chance that it is already installed on your system. If you want a more recent version of GnuPG you could build it on your own, but that is not necessary, if you don't need the latest features ;-) Greetings, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Tue Jan 4 14:13:27 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 4 Jan 2022 13:13:27 +0000 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: Message-ID: <51AEBDC9-84C6-445E-8C30-AE3E6160023E@andrewg.com> > On 4 Jan 2022, at 12:15, Alex Nadtoka wrote: > > yes thanks, tried disabling it but error was still there. So I deleted DST Root CA X3 . At the mooment I see error from dirmngr 2.3.4: no CA certificate found > And > error searching keyserver: "No inquire callback in IPC" > > Not sure if it is still because of root certificate. Will try to google now You probably don?t have the new root certificate installed then. You should be able to download it from letsencrypt.org A -------------- next part -------------- An HTML attachment was scrubbed... URL: From johndoe65534 at mail.com Tue Jan 4 13:38:10 2022 From: johndoe65534 at mail.com (john doe) Date: Tue, 4 Jan 2022 13:38:10 +0100 Subject: Install gnupg on Linux machine ( For gpg encryption & decryption ) In-Reply-To: References: Message-ID: On 1/4/2022 4:17 AM, Rayapati Rama Rao (NCS) wrote: > Hi Team, > > Good Morning! > > Could you please let me know which gnupg software to download for Linux machine to make use of gpg encryption & decryption. > Also, may I know if any packages required to install on Linux prior to gnupg installation. > If possible could you please provide me the steps to install gnupg on Linux machine. > Thanks in advance, have a wonderful day. > Can't you simply use the package manager of your distribution? -- John Doe From alex.nadtoka at gmail.com Tue Jan 4 15:09:51 2022 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Tue, 4 Jan 2022 16:09:51 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: <51AEBDC9-84C6-445E-8C30-AE3E6160023E@andrewg.com> References: <51AEBDC9-84C6-445E-8C30-AE3E6160023E@andrewg.com> Message-ID: I do have isntalled ISRG Root X1 and X2 But I noticed that DST Root CA X3 appeared again in the system... weird. deleted it with admin privileges from entire PC ??, 4 ???. 2022 ?. ? 15:14 Andrew Gallagher via Gnupg-users < gnupg-users at gnupg.org> ????: > > On 4 Jan 2022, at 12:15, Alex Nadtoka wrote: > > yes thanks, tried disabling it but error was still there. So I deleted DST > Root CA X3 . At the mooment I see error from dirmngr 2.3.4: no CA > certificate found > And > error searching keyserver: "No inquire callback in IPC" > Not sure if it is still because of root certificate. Will try to google now > > > You probably don?t have the new root certificate installed then. You > should be able to download it from letsencrypt.org > > A > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anze at anze.dev Wed Jan 5 01:26:38 2022 From: anze at anze.dev (Anze Jensterle) Date: Wed, 5 Jan 2022 01:26:38 +0100 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: <51AEBDC9-84C6-445E-8C30-AE3E6160023E@andrewg.com> Message-ID: I am having the same issue on GnuPG version 2.3.4. If I have the DST root in my Trust Root Store I get Certificate expired, if I don't have it in there I get "No inquire callback in IPC" and Dirmngr logs "error connecting to 'https://keys.openpgp.org:443': Missing issuer certificate". Any idea why this would still happen? Best, Anze On Tue, Jan 4, 2022 at 3:46 PM Alex Nadtoka via Gnupg-users < gnupg-users at gnupg.org> wrote: > I do have isntalled ISRG Root X1 and X2 > But I noticed that DST Root CA X3 appeared again in the system... weird. > deleted it with admin privileges from entire PC > > ??, 4 ???. 2022 ?. ? 15:14 Andrew Gallagher via Gnupg-users < > gnupg-users at gnupg.org> ????: > >> >> On 4 Jan 2022, at 12:15, Alex Nadtoka wrote: >> >> yes thanks, tried disabling it but error was still there. So I deleted DST >> Root CA X3 . At the mooment I see error from dirmngr 2.3.4: no CA >> certificate found >> And >> error searching keyserver: "No inquire callback in IPC" >> Not sure if it is still because of root certificate. Will try to google >> now >> >> >> You probably don?t have the new root certificate installed then. You >> should be able to download it from letsencrypt.org >> >> A >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anze at anze.dev Wed Jan 5 01:43:58 2022 From: anze at anze.dev (Anze Jensterle) Date: Wed, 5 Jan 2022 01:43:58 +0100 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: <51AEBDC9-84C6-445E-8C30-AE3E6160023E@andrewg.com> Message-ID: OK, I seem to have solved the issue. @Alex Nadtoka Deleting the DST Root is not needed. Make sure to delete the certificate name "Let's Encrypt X1" or similar and "R3" from the user and system store. They are not stored under "Trusted Roots" but under "Intermediate CAs". After I deleted all the old cached intermediates I am able to use a keyserver again. Best, Anze On Wed, Jan 5, 2022 at 1:26 AM Anze Jensterle wrote: > I am having the same issue on GnuPG version 2.3.4. > If I have the DST root in my Trust Root Store I get Certificate expired, > if I don't have it in there I get "No inquire callback in IPC" and Dirmngr > logs "error connecting to 'https://keys.openpgp.org:443': Missing issuer > certificate". > Any idea why this would still happen? > > Best, > Anze > > On Tue, Jan 4, 2022 at 3:46 PM Alex Nadtoka via Gnupg-users < > gnupg-users at gnupg.org> wrote: > >> I do have isntalled ISRG Root X1 and X2 >> But I noticed that DST Root CA X3 appeared again in the system... weird. >> deleted it with admin privileges from entire PC >> >> ??, 4 ???. 2022 ?. ? 15:14 Andrew Gallagher via Gnupg-users < >> gnupg-users at gnupg.org> ????: >> >>> >>> On 4 Jan 2022, at 12:15, Alex Nadtoka wrote: >>> >>> yes thanks, tried disabling it but error was still there. So I deleted DST >>> Root CA X3 . At the mooment I see error from dirmngr 2.3.4: no CA >>> certificate found >>> And >>> error searching keyserver: "No inquire callback in IPC" >>> Not sure if it is still because of root certificate. Will try to google >>> now >>> >>> >>> You probably don?t have the new root certificate installed then. You >>> should be able to download it from letsencrypt.org >>> >>> A >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Wed Jan 5 02:51:05 2022 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 04 Jan 2022 20:51:05 -0500 Subject: Install gnupg on Linux machine ( For gpg encryption & decryption ) In-Reply-To: Message-ID: <20220105015105.CB2C680404B@smtp.hushmail.com> On 1/4/2022 at 7:23 AM, "Rayapati Rama Rao (NCS)" wrote Could you please let me know which gnupg software to download for Linux machine to make use of gpg encryption & decryption. Also, may I know if any packages required to install on Linux prior to gnupg installation. If possible could you please provide me the steps to install gnupg on Linux machine. ===== Here is the Gnupg site for Gnupg downloads. The Linux links are listed below the ones for Windows and Mac. https://gnupg.org/download/index.html Once gnupg 2.2.33 is installed on your Linux system, you can download Kleopatra as an easy gui front end. https://www.openpgp.org/software/kleopatra/ If you do not especially need the Linux version you are using, I would highly recommend the Ubuntu 20.x LTS (long term support). It already has Gnupg installed by default when you download the .iso https://ubuntu.com/download#download All the Best Vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.nadtoka at gmail.com Wed Jan 5 09:16:52 2022 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Wed, 5 Jan 2022 10:16:52 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: <51AEBDC9-84C6-445E-8C30-AE3E6160023E@andrewg.com> Message-ID: I found one such certificate and removed it but the issue is still there. Is there a way to enable more detailed debug mode so I can see the path for the certificate that dirmngr is using? Regards, Oleksandr ??, 5 ???. 2022 ?. ? 02:44 Anze Jensterle ????: > OK, I seem to have solved the issue. > @Alex Nadtoka Deleting the DST Root is not > needed. Make sure to delete the certificate name "Let's Encrypt X1" or > similar and "R3" from the user and system store. They are not stored under > "Trusted Roots" but under "Intermediate CAs". After I deleted all the old > cached intermediates I am able to use a keyserver again. > > Best, > Anze > > On Wed, Jan 5, 2022 at 1:26 AM Anze Jensterle wrote: > >> I am having the same issue on GnuPG version 2.3.4. >> If I have the DST root in my Trust Root Store I get Certificate expired, >> if I don't have it in there I get "No inquire callback in IPC" and Dirmngr >> logs "error connecting to 'https://keys.openpgp.org:443': Missing issuer >> certificate". >> Any idea why this would still happen? >> >> Best, >> Anze >> >> On Tue, Jan 4, 2022 at 3:46 PM Alex Nadtoka via Gnupg-users < >> gnupg-users at gnupg.org> wrote: >> >>> I do have isntalled ISRG Root X1 and X2 >>> But I noticed that DST Root CA X3 appeared again in the system... >>> weird. deleted it with admin privileges from entire PC >>> >>> ??, 4 ???. 2022 ?. ? 15:14 Andrew Gallagher via Gnupg-users < >>> gnupg-users at gnupg.org> ????: >>> >>>> >>>> On 4 Jan 2022, at 12:15, Alex Nadtoka wrote: >>>> >>>> yes thanks, tried disabling it but error was still there. So I deleted DST >>>> Root CA X3 . At the mooment I see error from dirmngr 2.3.4: no CA >>>> certificate found >>>> And >>>> error searching keyserver: "No inquire callback in IPC" >>>> Not sure if it is still because of root certificate. Will try to google >>>> now >>>> >>>> >>>> You probably don?t have the new root certificate installed then. You >>>> should be able to download it from letsencrypt.org >>>> >>>> A >>>> _______________________________________________ >>>> Gnupg-users mailing list >>>> Gnupg-users at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>> >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.nadtoka at gmail.com Wed Jan 5 09:42:46 2022 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Wed, 5 Jan 2022 10:42:46 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: <51AEBDC9-84C6-445E-8C30-AE3E6160023E@andrewg.com> Message-ID: Ok for me the fix was by importing this intermediate certificate to intermediates in user profile and local computer https://letsencrypt.org/certs/lets-encrypt-r3.pem I guess old r3 should be removed and new one added Regards, Oleksandr ??, 5 ???. 2022 ?. ? 10:16 Alex Nadtoka ????: > I found one such certificate and removed it but the issue is still there. > Is there a way to enable more detailed debug mode so I can see the path for > the certificate that dirmngr is using? > > Regards, > Oleksandr > > ??, 5 ???. 2022 ?. ? 02:44 Anze Jensterle ????: > >> OK, I seem to have solved the issue. >> @Alex Nadtoka Deleting the DST Root is not >> needed. Make sure to delete the certificate name "Let's Encrypt X1" or >> similar and "R3" from the user and system store. They are not stored under >> "Trusted Roots" but under "Intermediate CAs". After I deleted all the old >> cached intermediates I am able to use a keyserver again. >> >> Best, >> Anze >> >> On Wed, Jan 5, 2022 at 1:26 AM Anze Jensterle wrote: >> >>> I am having the same issue on GnuPG version 2.3.4. >>> If I have the DST root in my Trust Root Store I get Certificate expired, >>> if I don't have it in there I get "No inquire callback in IPC" and Dirmngr >>> logs "error connecting to 'https://keys.openpgp.org:443': Missing >>> issuer certificate". >>> Any idea why this would still happen? >>> >>> Best, >>> Anze >>> >>> On Tue, Jan 4, 2022 at 3:46 PM Alex Nadtoka via Gnupg-users < >>> gnupg-users at gnupg.org> wrote: >>> >>>> I do have isntalled ISRG Root X1 and X2 >>>> But I noticed that DST Root CA X3 appeared again in the system... >>>> weird. deleted it with admin privileges from entire PC >>>> >>>> ??, 4 ???. 2022 ?. ? 15:14 Andrew Gallagher via Gnupg-users < >>>> gnupg-users at gnupg.org> ????: >>>> >>>>> >>>>> On 4 Jan 2022, at 12:15, Alex Nadtoka wrote: >>>>> >>>>> yes thanks, tried disabling it but error was still there. So I >>>>> deleted DST Root CA X3 . At the mooment I see error from dirmngr >>>>> 2.3.4: no CA certificate found >>>>> And >>>>> error searching keyserver: "No inquire callback in IPC" >>>>> Not sure if it is still because of root certificate. Will try to >>>>> google now >>>>> >>>>> >>>>> You probably don?t have the new root certificate installed then. You >>>>> should be able to download it from letsencrypt.org >>>>> >>>>> A >>>>> _______________________________________________ >>>>> Gnupg-users mailing list >>>>> Gnupg-users at gnupg.org >>>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>>> >>>> _______________________________________________ >>>> Gnupg-users mailing list >>>> Gnupg-users at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Jan 6 09:30:42 2022 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Jan 2022 09:30:42 +0100 Subject: Gpg4win LetsEncrypt issue In-Reply-To: (Alex Nadtoka via Gnupg-users's message of "Tue, 4 Jan 2022 14:14:47 +0200") References: Message-ID: <871r1lxo3x.fsf@wheatstone.g10code.de> Hi! instead of working around the problem, I strongly suggest to update gpg4win to 4.0 or at least install gnupg 2.2.33 on top of an older gpg4win. This fixes the problem without a need to tweak the root cert store. 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 anze at anze.dev Thu Jan 6 12:02:19 2022 From: anze at anze.dev (Anze Jensterle) Date: Thu, 6 Jan 2022 12:02:19 +0100 Subject: Gpg4win LetsEncrypt issue In-Reply-To: <871r1lxo3x.fsf@wheatstone.g10code.de> References: <871r1lxo3x.fsf@wheatstone.g10code.de> Message-ID: Hi Werner, This was happening to me on the latest 2.3.4 with gpg4win 4. Any idea why? I suspect it has to do with old intermediates being crosssigned as well. Best, Anze On Thu, 6 Jan 2022 at 09:41 Werner Koch via Gnupg-users < gnupg-users at gnupg.org> wrote: > Hi! > > instead of working around the problem, I strongly suggest to update > gpg4win to 4.0 or at least install gnupg 2.2.33 on top of an older > gpg4win. This fixes the problem without a need to tweak the root cert > store. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Jan 6 15:29:26 2022 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Jan 2022 15:29:26 +0100 Subject: Gpg4win LetsEncrypt issue In-Reply-To: (Anze Jensterle's message of "Thu, 6 Jan 2022 12:02:19 +0100") References: <871r1lxo3x.fsf@wheatstone.g10code.de> Message-ID: <87wnjdued5.fsf@wheatstone.g10code.de> On Thu, 6 Jan 2022 12:02, Anze Jensterle said: > Any idea why? I suspect it has to do with old intermediates being > crosssigned as well. If you don't have the current LE root certificate the old certification path is tried. 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 anze at anze.dev Thu Jan 6 15:33:10 2022 From: anze at anze.dev (Anze Jensterle) Date: Thu, 6 Jan 2022 15:33:10 +0100 Subject: Gpg4win LetsEncrypt issue In-Reply-To: <87wnjdued5.fsf@wheatstone.g10code.de> References: <871r1lxo3x.fsf@wheatstone.g10code.de> <87wnjdued5.fsf@wheatstone.g10code.de> Message-ID: That's the weird thing: I had the new root installed all this time (I checked multiple times). Only deleting the old intermediates instead of the root helped. Do you also check all the intermediate paths? So the path to verify was SERVER->INTERMEDIATE(R3 signed by DST Root)->DST ROOT, both the SERVER->INTERMEDIATE (R3 signed by ISRG Root X1)->ISRG ROOT (cross-signed by DST), or the SERVER->INTERMEDIATE (R3 signed by ISRG Root X1)->ISRG ROOT (self-signed) never happened. Best, Anze On Thu, Jan 6, 2022 at 3:30 PM Werner Koch wrote: > On Thu, 6 Jan 2022 12:02, Anze Jensterle said: > > > Any idea why? I suspect it has to do with old intermediates being > > crosssigned as well. > > If you don't have the current LE root certificate the old certification > path is tried. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.nadtoka at gmail.com Thu Jan 6 16:22:54 2022 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Thu, 6 Jan 2022 17:22:54 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: <871r1lxo3x.fsf@wheatstone.g10code.de> References: <871r1lxo3x.fsf@wheatstone.g10code.de> Message-ID: yes as well as for me. I was using latest gpg software Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> ??, 6 ???. 2022 ?. ? 10:32 Werner Koch ????: > Hi! > > instead of working around the problem, I strongly suggest to update > gpg4win to 4.0 or at least install gnupg 2.2.33 on top of an older > gpg4win. This fixes the problem without a need to tweak the root cert > store. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at pgp.16bits.net Thu Jan 6 22:53:36 2022 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Thu, 06 Jan 2022 22:53:36 +0100 Subject: [Announce] A New Future for GnuPG In-Reply-To: <871r1p1e2p.fsf@wheatstone.g10code.de> References: <871r1p1e2p.fsf@wheatstone.g10code.de> Message-ID: <4df036936677bb2f8aa408186fc31d96ee1ef0e2.camel@16bits.net> On 2022-01-03 at 08:19 +0100, Werner Koch wrote: > Hello and a Happy Gnu Year! > > It has been quite some time since my last status report on GnuPG. I > have been quite busy working on the project but unfortunately rarely > active on the usual channels. So, here is a new report telling what > we did over the last two or three years. I can only say... Congratulations! From foods.bolds_0y at icloud.com Fri Jan 7 06:45:09 2022 From: foods.bolds_0y at icloud.com (foods.bolds_0y at icloud.com) Date: Fri, 7 Jan 2022 13:45:09 +0800 Subject: Having two versions of GPG on Linux causes problem Message-ID: Hi, I installed two versions of GnuPG on Ubuntu using two package managers. GPG 2.2 is installed with built-in apt and GPG 2.3 is installed with LinuxBrew. The path of LinuxBrew has priority in the $PATH so it is invoked in the terminal (which is what I want). However whenever I uses it, it shows the message ?server gpg-agent is older than us (2.2.20 < 2.3.4)?. It seems that GPG 2.3 invoked the old version of gpg-agent residing in /usr/bin. I cannot delete the old gpg because it is a dependency of other software. Running ?gpgconf kill ?all? won?t solve the problem, so does restarting the machine. What is strange is that running ?gpgconf list? shows the correct path of all the components, including gpg-agent. I installed two versions of GPG because I want to use the newest v2.3, which is not provided in any apt source as I know. Is there anyway to resolve the issue, or installing two versions is an undefined behaviour? Thanks in advance Meng -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlikonen at iki.fi Fri Jan 7 12:28:51 2022 From: tlikonen at iki.fi (Teemu Likonen) Date: Fri, 07 Jan 2022 13:28:51 +0200 Subject: Having two versions of GPG on Linux causes problem In-Reply-To: References: Message-ID: <871r1jzswc.fsf@iki.fi> * 2022-01-07 13:45:09+0800, foods.bolds wrote: > I installed two versions of GnuPG on Ubuntu using two package > managers. > It seems that GPG 2.3 invoked the old version of gpg-agent residing in > /usr/bin. I cannot delete the old gpg because it is a dependency of > other software. Probably there is a systemd unit gpg-agent.socket which listens to connections on a socket and starts unit gpg-agent.service which starts /usr/bin/gpg-agent. If that is the case you can override the .service unit. Write a .conf file which overrides just the ExecStart= and ExecReload= settings, like this: # /etc/systemd/user/gpg-agent.service.d/my.conf # or maybe: # ~/.config/systemd/user/gpg-agent.service.d/my.conf [Service] ExecStart=/usr/local/bin/gpg-agent --supervised ExecReload=/usr/local/bin/gpgconf --reload gpg-agent Then: systemctl --user stop gpg-agent.service systemctl --user daemon-reload -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 434 bytes Desc: not available URL: From bernhard at intevation.de Fri Jan 7 15:06:06 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 7 Jan 2022 15:06:06 +0100 Subject: one ecc key-pair for both encryption and signature? Message-ID: <202201071506.12990.bernhard@intevation.de> With 2.2.33 is is not possible to create a single ecc key-pair that can do "sign" and "encrypt". I know that "ed25519" and "cv25519" are different algorithms, but from my limited understanding the same key-pair should be usable for both encrypting and signing in theory? Can someone point me to an explanation why it isn't done so here? Thanks Bernhard == Details GNUPGHOME=~/dot-gnupg-test3/ gpg --expert --full-generate-keygpg: WARNING: gpg (GnuPG) 2.2.33; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC and ECC (10) ECC (sign only) (11) ECC (set your own capabilities) (13) Existing key (14) Existing key from card Your selection? 11 Possible actions for a ECDSA/EdDSA key: Sign Certify Authenticate Current allowed actions: Sign Certify (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished Your selection? e Invalid selection. -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Fri Jan 7 15:21:45 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 7 Jan 2022 14:21:45 +0000 Subject: one ecc key-pair for both encryption and signature? In-Reply-To: <202201071506.12990.bernhard@intevation.de> References: <202201071506.12990.bernhard@intevation.de> Message-ID: <1408b149-cd39-9cc9-70cc-6e76bbd6b342@andrewg.com> On 07/01/2022 14:06, Bernhard Reiter wrote: > With 2.2.33 is is not possible to create a single ecc key-pair > that can do "sign" and "encrypt". There are circumstances (legal, contractual, operational) where you may need to disclose or share an encryption key, so it is best practice to keep the encryption-capable subkey distinct. And if you present people with the option to do a suboptimal thing, a significant fraction of them will choose that option by accident - so usually best not to offer it in the first place. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Jan 7 15:26:50 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 7 Jan 2022 09:26:50 -0500 Subject: one ecc key-pair for both encryption and signature? In-Reply-To: <202201071506.12990.bernhard@intevation.de> References: <202201071506.12990.bernhard@intevation.de> Message-ID: > I know that "ed25519" and "cv25519" are different algorithms, > but from my limited understanding the same key-pair should be > usable for both encrypting and signing in theory? Ed25519 is (effectively) a Schnorr signature done over an Edwards curve. Schnorr signatures have really no capability of being used for encryption, unless you want to do it just a few bytes at a time. Schnorr signatures were also used as the basis for DSA during the cryptowars of the 1990s. The US government was very worried that any federal crypto standard not be able to be used for encryption (seriously): they wanted to give American citizens and businesses a strong signature algorithm, but not give us a strong encryption algorithm. Hence, Schnorr was adapted into becoming the Digital Signature Algorithm... From bozho at kset.org Fri Jan 7 16:23:05 2022 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Fri, 7 Jan 2022 16:23:05 +0100 Subject: Yubikeys and GnuPG 2.2/2.3 Message-ID: <1b3ae727-ee8b-865b-ea6a-7ba6ab3dfae4@kset.org> Hi all, I run GnuPG 2.2.27 on Windows 10 and gpg-agent + ssh-pageant (from Cygwin) with Yubikey NEO for my SSH needs. For some time now, gpg-agent has problems detecting my Yubikey. Windows sometimes detects Yubikey as "Unknown Smart Card" and I used to resort to manually updating the driver to get it recognised as "Identity Device (NIST SP 800-73 [PIV])" and then reinserting my Yubikey a few times until gpg --card-status command recognised Yubikey. This used to "hold" between computer reboots, but lately has been happening almost every time I reinsert Yubikey NEO. To avoid furiously reinserting the key and risk breaking something, I wrote a small PowerShell function that does this (kill scdaemon, restart Windows Smart Card service and try reading card status): do { & gpgconf --kill scdaemon Restart-Service SCardSvr & gpg --card-status -vvv } while ($LASTEXITCODE -ne 0) This usually works after a few loops. I have both Yubikey NEO and Yubikey 5 and both have the same problem. My scdaemon.conf has a single line: card-timeout 1 I tried debugging scdaemon a bit, so I added these lines to scdaemon.conf: log-file debug-level basic verbose After killing scdaemon.exe and running gpg --card-status, I get: 2022-01-07 15:53:58 scdaemon[9960] listening on socket '\.gnupg\S.scdaemon' 2022-01-07 15:53:58 scdaemon[9960] handler for fd -1 started 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK GNU Privacy Guard's Smartcard server ready 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- GETINFO socket_name 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> D \.gnupg\S.scdaemon 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- OPTION event-signal=0x00000284 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- GETINFO version 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> D 2.2.27 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- SERIALNO 2022-01-07 15:53:58 scdaemon[9960] detected reader 'Yubico Yubikey NEO OTP+U2F+CCID 0' 2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected 2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation (0x8010000b) 2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> ERR 100696144 No such device 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- RESTART 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK When I run my "fixing" loop, I'll get a few of these blocks and then a success. Recently, I tried upgrading to GnuPG 2.3.4 and my "fixing" loop does not work at all. Debugging scdaemon with Yubikey NEO, I get something like this: 2022-01-07 15:48:05 scdaemon[24108] listening on socket '\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon' 2022-01-07 15:48:05 scdaemon[24108] handler for fd -1 started 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK GNU Privacy Guard's Smartcard server ready 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- GETINFO socket_name 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> D \AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- OPTION event-signal=290 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- GETINFO version 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> D 2.3.4 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- SERIALNO 2022-01-07 15:48:05 scdaemon[24108] detected reader 'Yubico Yubikey NEO OTP+U2F+CCID 0' 2022-01-07 15:48:05 scdaemon[24108] reader slot 0: not connected 2022-01-07 15:48:05 scdaemon[24108] reader slot 0: active protocol: T1 2022-01-07 15:48:05 scdaemon[24108] slot 0: ATR=3bfc1300008131fe15597562696b65794e454f7233e1 2022-01-07 15:48:05 scdaemon[24108] no supported card application found: Card error 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> S PINCACHE_PUT 0// 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> ERR 100696144 No such device 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- RESTART 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK With Yubikey 5, I get: 2022-01-07 15:48:46 scdaemon[15680] listening on socket '\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon' 2022-01-07 15:48:46 scdaemon[15680] handler for fd -1 started 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK GNU Privacy Guard's Smartcard server ready 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- GETINFO socket_name 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> D \AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- OPTION event-signal=290 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- GETINFO version 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> D 2.3.4 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- SERIALNO 2022-01-07 15:48:46 scdaemon[15680] detected reader 'Yubico YubiKey OTP+FIDO+CCID 0' 2022-01-07 15:48:46 scdaemon[15680] reader slot 0: not connected 2022-01-07 15:48:46 scdaemon[15680] pcsc_connect failed: sharing violation (0x8010000b) 2022-01-07 15:48:46 scdaemon[15680] reader slot 0: not connected 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> S PINCACHE_PUT 0// 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> ERR 100696144 No such device 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- RESTART 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK If I add "psc-shared" option to scdaemon.conf and use Yubikey 5, gpg --card-status works every time, but I still get "no supported card application found: Card error" for Yubikey NEO. Is there any way to get Yubikey NEO working with GnuPG 2.3? Thank you, -- Marko Bo?ikovi? -- Marko Bo?ikovi? From bernhard at intevation.de Fri Jan 7 17:55:50 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 7 Jan 2022 17:55:50 +0100 Subject: one ecc key-pair for both encryption and signature? In-Reply-To: <1408b149-cd39-9cc9-70cc-6e76bbd6b342@andrewg.com> References: <202201071506.12990.bernhard@intevation.de> <1408b149-cd39-9cc9-70cc-6e76bbd6b342@andrewg.com> Message-ID: <202201071756.09777.bernhard@intevation.de> Am Freitag 07 Januar 2022 15:21:45 schrieb Andrew Gallagher via Gnupg-users: > On 07/01/2022 14:06, Bernhard Reiter wrote: > > With 2.2.33 is is not possible to create a single ecc key-pair > > that can do "sign" and "encrypt". > > it is best practice to keep the encryption-capable subkey distinct. Is this the only reason? Then RSA should be limited in the same way. (Because there it is possible, so I guess that there is another reason.) Am Freitag 07 Januar 2022 15:26:50 schrieb Robert J. Hansen via Gnupg-users: > Ed25519 is (effectively) a Schnorr signature done over an Edwards curve. > Schnorr signatures have really no capability of being used for > encryption, unless you want to do it just a few bytes at a time. Reading https://en.wikipedia.org/wiki/Curve25519 | Curve25519 is an elliptic curve [..] designed for use with the elliptic | curve Diffie?Hellman (ECDH) key agreement scheme -> encrypt | The curve is birationally equivalent to a twisted Edwards curve | used in the Ed25519 signature scheme. There is anequivalence given (two functions) in the Ed25519 wikipedia page, but I don't know if this allows the same curve used in both algorithms. Regards Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Fri Jan 7 18:26:17 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 7 Jan 2022 17:26:17 +0000 Subject: one ecc key-pair for both encryption and signature? In-Reply-To: <202201071756.09777.bernhard@intevation.de> References: <202201071506.12990.bernhard@intevation.de> <1408b149-cd39-9cc9-70cc-6e76bbd6b342@andrewg.com> <202201071756.09777.bernhard@intevation.de> Message-ID: On 07/01/2022 16:55, Bernhard Reiter wrote: > > Then RSA should be limited in the same way. > (Because there it is possible, so I guess that there is another reason.) I agree, although IIRC such usage is supported for backwards compatibility reasons. > | The curve is birationally equivalent to a twisted Edwards curve > | used in the Ed25519 signature scheme. > > There is anequivalence given (two functions) in the Ed25519 wikipedia page, > but I don't know if this allows the same curve used in both algorithms. "Birationally equivalent" means that there is a 1:1 mapping between the points of each curve that preserves their mathematical structure. This means that you could in principle convert a key from one curve to the other, but it would be a more complex function than just copying the raw bit string. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Fri Jan 7 20:02:01 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 7 Jan 2022 20:02:01 +0100 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: Message-ID: <202201072002.23707.bernhard@intevation.de> Am Mittwoch 05 Januar 2022 09:16:52 schrieb Alex Nadtoka via Gnupg-users: > Is there a way to enable more detailed debug mode so I can see the path for > the certificate that dirmngr is using? Use dirmngr.conf to add more diagnostic output, e.g. log-file c:\XYZ debug-level advanced and restart dirmngr and do a request. (reload could be done by gpgconf --reload dirmngr ) Regards Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Fri Jan 7 20:23:33 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 7 Jan 2022 14:23:33 -0500 Subject: one ecc key-pair for both encryption and signature? In-Reply-To: <202201071756.09777.bernhard@intevation.de> References: <202201071506.12990.bernhard@intevation.de> <1408b149-cd39-9cc9-70cc-6e76bbd6b342@andrewg.com> <202201071756.09777.bernhard@intevation.de> Message-ID: > There is anequivalence given (two functions) in the Ed25519 wikipedia page, > but I don't know if this allows the same curve used in both algorithms. Yes, in the same way that if you torture a DSA key long enough you can get the Elgamal encryption algorithm out of it. But once you do that, *you're no longer using DSA*. Likewise, Edwards DSA can be tortured into becoming a Curve25519 key. But once you do that, *you're no longer using Edwards DSA*. From marko.bozikovic at gmail.com Fri Jan 7 16:12:35 2022 From: marko.bozikovic at gmail.com (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Fri, 7 Jan 2022 16:12:35 +0100 Subject: Yubikeys and GnuPG 2.2/2.3 Message-ID: Hi all, I run GnuPG 2.2.27 on Windows 10 and gpg-agent + ssh-pageant (from Cygwin) with Yubikey NEO for my SSH needs. For some time now, gpg-agent has problems detecting my Yubikey. Windows sometimes detects Yubikey as "Unknown Smart Card" and I used to resort to manually updating the driver to get it recognised as "Identity Device (NIST SP 800-73 [PIV])" and then reinserting my Yubikey a few times until gpg --card-status command recognised Yubikey. This used to "hold" between computer reboots, but lately has been happening almost every time I reinsert Yubikey NEO. To avoid furiously reinserting the key and risk breaking something, I wrote a small PowerShell function that does this (kill scdaemon, restart Windows Smart Card service and try reading card status): do { & gpgconf --kill scdaemon Restart-Service SCardSvr & gpg --card-status -vvv } while ($LASTEXITCODE -ne 0) This usually works after a few loops. I have both Yubikey NEO and Yubikey 5 and both have the same problem. My scdaemon.conf has a single line: card-timeout 1 I tried debugging scdaemon a bit, so I added these lines to scdaemon.conf: log-file debug-level basic verbose After killing scdaemon.exe and running gpg --card-status, I get: 2022-01-07 15:53:58 scdaemon[9960] listening on socket '\.gnupg\S.scdaemon' 2022-01-07 15:53:58 scdaemon[9960] handler for fd -1 started 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK GNU Privacy Guard's Smartcard server ready 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- GETINFO socket_name 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> D \.gnupg\S.scdaemon 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- OPTION event-signal=0x00000284 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- GETINFO version 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> D 2.2.27 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- SERIALNO 2022-01-07 15:53:58 scdaemon[9960] detected reader 'Yubico Yubikey NEO OTP+U2F+CCID 0' 2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected 2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation (0x8010000b) 2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> ERR 100696144 No such device 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- RESTART 2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK When I run my "fixing" loop, I'll get a few of these blocks and then a success. Recently, I tried upgrading to GnuPG 2.3.4 and my "fixing" loop does not work at all. Debugging scdaemon with Yubikey NEO, I get something like this: 2022-01-07 15:48:05 scdaemon[24108] listening on socket '\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon' 2022-01-07 15:48:05 scdaemon[24108] handler for fd -1 started 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK GNU Privacy Guard's Smartcard server ready 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- GETINFO socket_name 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> D \AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- OPTION event-signal=290 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- GETINFO version 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> D 2.3.4 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- SERIALNO 2022-01-07 15:48:05 scdaemon[24108] detected reader 'Yubico Yubikey NEO OTP+U2F+CCID 0' 2022-01-07 15:48:05 scdaemon[24108] reader slot 0: not connected 2022-01-07 15:48:05 scdaemon[24108] reader slot 0: active protocol: T1 2022-01-07 15:48:05 scdaemon[24108] slot 0: ATR=3bfc1300008131fe15597562696b65794e454f7233e1 2022-01-07 15:48:05 scdaemon[24108] no supported card application found: Card error 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> S PINCACHE_PUT 0// 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> ERR 100696144 No such device 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- RESTART 2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK With Yubikey 5, I get: 2022-01-07 15:48:46 scdaemon[15680] listening on socket '\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon' 2022-01-07 15:48:46 scdaemon[15680] handler for fd -1 started 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK GNU Privacy Guard's Smartcard server ready 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- GETINFO socket_name 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> D \AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- OPTION event-signal=290 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- GETINFO version 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> D 2.3.4 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- SERIALNO 2022-01-07 15:48:46 scdaemon[15680] detected reader 'Yubico YubiKey OTP+FIDO+CCID 0' 2022-01-07 15:48:46 scdaemon[15680] reader slot 0: not connected 2022-01-07 15:48:46 scdaemon[15680] pcsc_connect failed: sharing violation (0x8010000b) 2022-01-07 15:48:46 scdaemon[15680] reader slot 0: not connected 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> S PINCACHE_PUT 0// 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> ERR 100696144 No such device 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- RESTART 2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK If I add "psc-shared" option to scdaemon.conf and use Yubikey 5, gpg --card-status works every time, but I still get "no supported card application found: Card error" for Yubikey NEO. Is there any way to get Yubikey NEO working with GnuPG 2.3? Thank you, -- Marko Bo?ikovi? From r.flosbach at gmx.de Sat Jan 8 10:01:53 2022 From: r.flosbach at gmx.de (Robert Flosbach) Date: Sat, 8 Jan 2022 10:01:53 +0100 Subject: GPG key generated on Windows and imported on Linux fails to decrypt files on Linux which where encrypted on Windows Message-ID: <001201d8046e$61b20540$25160fc0$@gmx.de> Hello everyone, I've created a private key on my Windows 10 machine with Gpg4win/Kleopatra and imported it on my Linux machine. Now, when I encrypt files with Gpg4win on Windows (via Kleopatra) and try to decrypt them on a Linux machine, I get the following error: gpg: [don't know]: partial length invalid for packet type 20 Steps to reproduce: 1) Install Gpg4win 4.0.0 on Windows 10. 2) Generate keypair with default settings on Windows. 3) Export keypair and import it on a Linux machine. 4) Encrypt a file on Windows, copy it on the Linux machine and try to decrypt it [1]. Some more information: 1) The other way round (signing/encrypting on Linux and verifying/decrypting on Windows) works without a problem. 2) Also signing/encrypting on Linux and verifying/decrypting on Linux works without a problem. 2) I used a plain Windows 10 VM and a plain Ubuntu 20.04 VM to reproduce the bug so exclude configuration problems. 3) On Windows I use: Gpg4win 4.0.0 with GnuPG 2.3.4, Libgcrypt 1.9.4. On Linux Ubuntu 20.04 and 18.04 I use gpg (GnuPG) 2.2.19, libgcrypt 1.8.5 and gpg (GnuPG) 2.2.4, libgcrypt 1.8.1. 4) First I thought that the problem was encrypting on Windows and decrypting on Linux. However, the problem might rather have to do with the key generation/export/import somehow, because if I generate a private key on Linux and transfer it to Windows, then I can encrypt files on Windows and decrypt them on Linux! 5) Importing the key on Linux does not generate any warning or error. And I can also properly use the keypair generated on Windows to encrypt, decrypt, sign and verify files between Linux clients without problem. It's just encrypting on Windows and decrypting on Linux with a keypair generated on a Windows client. If anyone of you recognize the problem and has a solution, please tell me what I did wrong or what I could do to decrypt my files on Linux. Maybe there are some known incompatibilities that I failed to find while researching the bug. Otherwise, it would be great to open a bug for this issue. Kind regards Robert Flosbach [1] Verbose commandline output: gpg -vv --decrypt test.txt.gpg # off=0 ctb=85 tag=1 hlen=3 plen=524 :pubkey enc packet: version 3, algo 1, keyid E99307B0267B183D data: [4094 bits] gpg: public key is E99307B0267B183D gpg: using subkey E99307B0267B183D instead of primary key 644B2234DE0FC2F0 gpg: public key encrypted data: good DEK gpg: [don't know]: partial length invalid for packet type 20 From rjh at sixdemonbag.org Sat Jan 8 14:41:36 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 8 Jan 2022 08:41:36 -0500 Subject: GPG key generated on Windows... In-Reply-To: <001201d8046e$61b20540$25160fc0$@gmx.de> References: <001201d8046e$61b20540$25160fc0$@gmx.de> Message-ID: <4b84d64b-a023-0644-e94f-e5e612a00a1b@sixdemonbag.org> > 5) Importing the key on Linux does not generate any warning or error. And I > can also properly use the keypair generated on Windows to encrypt, decrypt, > sign and verify files between Linux clients without problem. It's just > encrypting on Windows and decrypting on Linux with a keypair generated on a > Windows client. GnuPG has made some long-overdue changes between 2.2 and 2.3. 2.2 defaults to "let's generate traffic like we've done since 2000", and 2.3 defaults to "let's use some newer and better cryptography". It's possible to create traffic in 2.3 that cannot be read in 2.2. Adding "rfc4880" to your %APPDATA%\gnupg\gpg.conf file on your Windows box might help: this forces GnuPG to use the older style of cryptography. Let us know if this helps! -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From r.flosbach at gmx.de Sun Jan 9 10:25:39 2022 From: r.flosbach at gmx.de (Robert Flosbach) Date: Sun, 9 Jan 2022 10:25:39 +0100 Subject: AW: GPG key generated on Windows... In-Reply-To: <4b84d64b-a023-0644-e94f-e5e612a00a1b@sixdemonbag.org> References: <001201d8046e$61b20540$25160fc0$@gmx.de> <4b84d64b-a023-0644-e94f-e5e612a00a1b@sixdemonbag.org> Message-ID: <003a01d8053a$de2469c0$9a6d3d40$@gmx.de> Thank you very much for your help! For future reference and people having the same issue: gpg2.3 introduced a new packet type 20 which provides authenticated encryption with associated data (AEAD) [1]. A key generated with gpg2.3 supports this encryption type and encryption in Windows (using the current Gpg4win 4.0.0) defaults to AEAD for a key generated with default settings. Since AEAD/type 20 is not supported yet by version 2.2, decryption on linux distros is not possible using version 2.2.X from their repositories. [1] https://tools.ietf.org/id/draft-ietf-openpgp-rfc4880bis-06.html#rfc.section.5.16 From wk at gnupg.org Sun Jan 9 12:14:27 2022 From: wk at gnupg.org (Werner Koch) Date: Sun, 09 Jan 2022 12:14:27 +0100 Subject: AW: GPG key generated on Windows... In-Reply-To: <003a01d8053a$de2469c0$9a6d3d40$@gmx.de> (Robert Flosbach via Gnupg-users's message of "Sun, 9 Jan 2022 10:25:39 +0100") References: <001201d8046e$61b20540$25160fc0$@gmx.de> <4b84d64b-a023-0644-e94f-e5e612a00a1b@sixdemonbag.org> <003a01d8053a$de2469c0$9a6d3d40$@gmx.de> Message-ID: <87h7adtb3g.fsf@wheatstone.g10code.de> On Sun, 9 Jan 2022 10:25, Robert Flosbach said: > For future reference and people having the same issue: gpg2.3 > introduced a new packet type 20 which provides authenticated > encryption with associated data (AEAD) [1]. A key generated with > gpg2.3 supports this encryption type and encryption in Windows (using > the current Gpg4win 4.0.0) defaults to AEAD for a key generated with There are two ways to change this: the first is to change the preferences on your key (using 2.3's --edit-key) and the second is to put --8<---------------cut here---------------start------------->8--- ignore-invalid-option personal-aead-preferences personal-aead-preferences none --8<---------------cut here---------------end--------------->8--- into gpg.conf . From the man page: --personal-aead-preferences string Set the list of personal AEAD preferences to string. Use gpg --version to get a list of available algorithms, and use none to set no preference at all. This allows the user to safely override the algorithm chosen by the recipient key preferences, as GPG will only select an algorithm that is usable by all recipients. The most highly ranked cipher in this list is also used for the --symmetric encryption command. (the ignore-invalid-option line allows to use the same gpg.conf also with gpg 2.2) 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 bernhard at intevation.de Mon Jan 10 10:39:27 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Jan 2022 10:39:27 +0100 Subject: one ecc key-pair for both encryption and signature? In-Reply-To: References: <202201071506.12990.bernhard@intevation.de> <202201071756.09777.bernhard@intevation.de> Message-ID: <202201101039.42816.bernhard@intevation.de> Am Freitag 07 Januar 2022 20:23:33 schrieb Robert J. Hansen via Gnupg-users: > > There is anequivalence given (two functions) in the Ed25519 wikipedia > > page, but I don't know if this allows the same curve used in both > > algorithms. > Likewise, Edwards DSA can be tortured into becoming a Curve25519 key. > But once you do that, *you're no longer using Edwards DSA*. Can you be more specific why this is a problem? Is it because the two transformation functions a) create numerical problems b) or runtime problems letting out information about the private key (thus being a side channel) c) or just the additional time needed for them ? (Andrew and Robert, thanks for your answers, you have already helped me to understand that detail better.) Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Jan 10 14:05:18 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Jan 2022 14:05:18 +0100 Subject: Yubikeys and GnuPG 2.2/2.3 In-Reply-To: <1b3ae727-ee8b-865b-ea6a-7ba6ab3dfae4@kset.org> ("Marko =?utf-8?B?Qm/Fvmlrb3ZpxIc=?= via Gnupg-users"'s message of "Fri, 7 Jan 2022 16:23:05 +0100") References: <1b3ae727-ee8b-865b-ea6a-7ba6ab3dfae4@kset.org> Message-ID: <87leznspv5.fsf@wheatstone.g10code.de> On Fri, 7 Jan 2022 16:23, Marko Bo?ikovi? said: > My scdaemon.conf has a single line: > > card-timeout 1 Please remove this at least for testing. > log-file > debug-level basic > verbose Please change the debug-level ... to debug ipc,app,cardio Actually you should have seen a debug line "Yubikey: config=" due to the verbose option. The "cardio" above returns all commands (so-called APDUs) send to the card. This should help to reveal the problem. > 2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation > (0x8010000b) Some other process is accessing the Yubikey. But as you already know pcsc-shared is a good workaround here which usually works fine. You may send me the log by PM if it is too large 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 2458099 at gmail.com Mon Jan 10 04:47:54 2022 From: 2458099 at gmail.com (Gilberto F. da Silva) Date: Mon, 10 Jan 2022 00:47:54 -0300 Subject: Fwd: gpg: onepass_sig with unknown version 105 In-Reply-To: References: Message-ID: ---------- Forwarded message --------- De: Gilberto F da Silva <2458099 at gmail.com> Date: seg., 10 de jan. de 2022 ?s 00:10 Subject: gpg: onepass_sig with unknown version 105 To: TradingView Saluton! When trying to use the Mageia 8 distribution I am getting this error. I use the .gnupg directory in common with other distributions. I deleted the symlink in /home from the Mageia distribution and re-imported a key. get the same error again when trying to open an .asc file Thanx in advance -- Stela dato:2.459.589,623 Loka tempo:2022-01-09 23:57:25 Diman?o -==- Um gato preto cruzando o seu caminho significa que o bicho est? indo para algum lugar. -- Groucho Marx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- -----BEGIN PGP SIGNATURE----- Comment: +-----------------------------------------------------+ Comment: ! Gilberto F da Silva - ICQ 136.782.571 ! Comment: +-----------------------------------------------------+ iEYEARECAAYFAmHbo7EACgkQJxugWtMhGw6k2QCffqMgGNsYGxmGkIU6Nn3+SoKP Y1IAoMNbHxaXlLLC1q3XcK/7o2q0QqHu =RGCL -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Mon Jan 10 16:07:54 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Jan 2022 10:07:54 -0500 Subject: one ecc key-pair for both encryption and signature? In-Reply-To: <202201101039.42816.bernhard@intevation.de> References: <202201071506.12990.bernhard@intevation.de> <202201071756.09777.bernhard@intevation.de> <202201101039.42816.bernhard@intevation.de> Message-ID: <98be9ce4-2f03-5948-30c7-419c327a3c0b@sixdemonbag.org> >> Likewise, Edwards DSA can be tortured into becoming a Curve25519 key. >> But once you do that, *you're no longer using Edwards DSA*. > > Can you be more specific why this is a problem? I apologize in advance for sounding grumpy (I am, it's been an annoying day so far) and condescending (which I'm trying not to be, but...). ===== I used to volunteer at my old elementary school. Due to budget cutbacks they had to eliminate their math program for gifted students, so I came in once every few weeks to talk to kids who should've been in gifted mathematics and try to keep their inspiration alive. I loved these kids: they were the best. One of my standard questions to them, early on each year, was "are addition and subtraction the same thing, just looked at differently?" And that's a great question to ask kids -- heck, even some adults! -- because it forces us to ask what it means to be the same thing. Ultimately, we start talking about not just what addition and subtraction do, but what the *nature* of them are. And ultimately we discover that addition and subtraction are two different things. The nature of addition is that it's both commutative (A + B) and associative (A + (B + C) = (A + B) + C). But subtraction is neither commutative nor associative. And that means that although each addition problem can be converted into a subtraction problem, and vice-versa, addition and subtraction are not the same, not at all. They're not "the same thing just looked at differently". The existence of a way to make one act like the other does not mean the same inputs can be used for both. ===== With me on the elementary-school algorithm theory? Please re-read that a few times, because I'm about to give *exactly the same lesson* except now I'm going to make it unnecessarily harder by talking about DSA and Elgamal keys. ===== A public key is not just a large prime number. It's an entire mathematical structure, of which a large prime number (or point on an elliptic curve, or what-have-you) is only one of many different components. For a DSA key you have to choose a hash algorithm H, key length L, a modulus N such that N < L and N <= len(H), an N-bit prime q, an L-bit prime p such that p-1 is a multiple of q, an integer randomly distributed among {2, p-2}, and finally, let g be h^((p-1)/q). Once you've done all of this, write down the triplet (p, q, g): these are your DSA parameters. Now choose an integer randomly distributed among {1, q-1} and compute y = g^x modulo p. Your private key is x, your public key is y. Now you're saying, "why can't I use the same x and y for Elgamal? I mean, they're both computing discrete logs over a finite field..." An Elgamal public key is closely related but different. For Elgamal, you need a cyclic group G of order q with generator g, an integer x randomly selected from {1, q-1}, and h = g^x. Your public key is (G, q, g, h) and your private key is x. You can see some similarities there. In both algorithms you need to select some random numbers, and you could view y = g^x modulo p as being a special case of h = g^x, and if you torture things enough you can *probably* create a one-to-one mapping between DSA signature keys and Elgamal encryption keys, what computer scientists call an isomorphism... ... *but that's not going to let you use the same key for both, because they're different algorithms*. Or, as I said: >> Likewise, Edwards DSA can be tortured into becoming a Curve25519 key. >> But once you do that, *you're no longer using Edwards DSA*. There is no possible universe in which "your public key is y, and oh, hey, post these parameters" can be used as "your public key is these four numbers". The fact one can be converted into the other via some kind of complex number-theoretic mapping does not mean they can ever be made directly interchangeable in algorithms that depend on keys having specific mathematical structures. (Disclaimers: I'm not a cryptographer. I am at best a cryptographic engineer. There are other people on this list far better suited than I to talk about the deeper mathematics of cryptography. Thanks to Wikipedia for having easily-available terse descriptions of these algorithms. Standard Wikipedia disclaimers apply: if you need authoritative descriptions look elsewhere, like the _Handbook of Applied Cryptography_.) From chris at christaylordeveloper.co.uk Mon Jan 10 19:48:03 2022 From: chris at christaylordeveloper.co.uk (Chris Taylor) Date: Mon, 10 Jan 2022 18:48:03 +0000 Subject: Gnupg-users Digest, Vol 220, Issue 11 In-Reply-To: References: Message-ID: Hello, Please unsubscribe me from this list. Chris On 10/01/2022 15:08, gnupg-users-request at gnupg.org wrote: > Send Gnupg-users mailing list submissions to > gnupg-users at gnupg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnupg.org/mailman/listinfo/gnupg-users > or, via email, send a message with subject or body 'help' to > gnupg-users-request at gnupg.org > > You can reach the person managing the list at > gnupg-users-owner at gnupg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnupg-users digest..." > > > Today's Topics: > > 1. AW: GPG key generated on Windows... (Robert Flosbach) > 2. Re: AW: GPG key generated on Windows... (Werner Koch) > 3. Re: one ecc key-pair for both encryption and signature? > (Bernhard Reiter) > 4. Re: Yubikeys and GnuPG 2.2/2.3 (Werner Koch) > 5. Fwd: gpg: onepass_sig with unknown version 105 > (Gilberto F. da Silva) > 6. Re: one ecc key-pair for both encryption and signature? > (Robert J. Hansen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 9 Jan 2022 10:25:39 +0100 > From: "Robert Flosbach" > To: > Subject: AW: GPG key generated on Windows... > Message-ID: <003a01d8053a$de2469c0$9a6d3d40$@gmx.de> > Content-Type: text/plain; charset="UTF-8" > > Thank you very much for your help! > > For future reference and people having the same issue: gpg2.3 introduced a new packet type 20 which provides authenticated encryption with associated data (AEAD) [1]. A key generated with gpg2.3 supports this encryption type and encryption in Windows (using the current Gpg4win 4.0.0) defaults to AEAD for a key generated with default settings. Since AEAD/type 20 is not supported yet by version 2.2, decryption on linux distros is not possible using version 2.2.X from their repositories. > > [1] https://tools.ietf.org/id/draft-ietf-openpgp-rfc4880bis-06.html#rfc.section.5.16 > > > > > ------------------------------ > > Message: 2 > Date: Sun, 09 Jan 2022 12:14:27 +0100 > From: Werner Koch > To: Robert Flosbach via Gnupg-users > Subject: Re: AW: GPG key generated on Windows... > Message-ID: <87h7adtb3g.fsf at wheatstone.g10code.de> > Content-Type: text/plain; charset="us-ascii" > > On Sun, 9 Jan 2022 10:25, Robert Flosbach said: > >> For future reference and people having the same issue: gpg2.3 >> introduced a new packet type 20 which provides authenticated >> encryption with associated data (AEAD) [1]. A key generated with >> gpg2.3 supports this encryption type and encryption in Windows (using >> the current Gpg4win 4.0.0) defaults to AEAD for a key generated with > There are two ways to change this: the first is to change the > preferences on your key (using 2.3's --edit-key) and the second is to > put > > --8<---------------cut here---------------start------------->8--- > ignore-invalid-option personal-aead-preferences > personal-aead-preferences none > --8<---------------cut here---------------end--------------->8--- > > into gpg.conf . From the man page: > > --personal-aead-preferences string > > Set the list of personal AEAD preferences to string. Use gpg > --version to get a list of available algorithms, and use none to set > no preference at all. This allows the user to safely override the > algorithm chosen by the recipient key preferences, as GPG will only > select an algorithm that is usable by all recipients. The most > highly ranked cipher in this list is also used for the --symmetric > encryption command. > > (the ignore-invalid-option line allows to use the same gpg.conf > also with gpg 2.2) > > > Shalom-Salam, > > Werner > > From andrewg at andrewg.com Mon Jan 10 22:05:47 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 10 Jan 2022 21:05:47 +0000 Subject: Gnupg-users Digest, Vol 220, Issue 11 In-Reply-To: References: Message-ID: > On 10 Jan 2022, at 20:33, Chris Taylor wrote: > > ?Hello, > > Please unsubscribe me from this list. Please follow the instructions that you quoted in the email you just sent: >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> or, via email, send a message with subject or body 'help' to >> gnupg-users-request at gnupg.org A From ryan at digicana.com Mon Jan 10 22:16:28 2022 From: ryan at digicana.com (Ryan McGinnis) Date: Mon, 10 Jan 2022 21:16:28 +0000 Subject: Gnupg-users Digest, Vol 220, Issue 11 In-Reply-To: References: Message-ID: Ah, it's nice to know that as time inexorably marches forward and Usenet becomes AOL becomes TikTok, as keyboards transition to phone screens transition to VR sensors, that some things, some things -- some things never change. -Ryan McGinnis ryan at digicana.com https://bigstormpicture.com GPG: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD ??????? Original Message ??????? On Monday, January 10th, 2022 at 12:48 PM, Chris Taylor wrote: > Hello, > > Please unsubscribe me from this list. > > Chris > > On 10/01/2022 15:08, gnupg-users-request at gnupg.org wrote: > > > Send Gnupg-users mailing list submissions to > > > > gnupg-users at gnupg.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > or, via email, send a message with subject or body 'help' to > > > > gnupg-users-request at gnupg.org > > > > You can reach the person managing the list at > > > > gnupg-users-owner at gnupg.org > > > > When replying, please edit your Subject line so it is more specific > > > > than "Re: Contents of Gnupg-users digest..." > > > > Today's Topics: > > > > 1. AW: GPG key generated on Windows... (Robert Flosbach) > > 2. Re: AW: GPG key generated on Windows... (Werner Koch) > > 3. Re: one ecc key-pair for both encryption and signature? > > (Bernhard Reiter) > > 4. Re: Yubikeys and GnuPG 2.2/2.3 (Werner Koch) > > 5. Fwd: gpg: onepass_sig with unknown version 105 > > (Gilberto F. da Silva) > > 6. Re: one ecc key-pair for both encryption and signature? > > (Robert J. Hansen) > > > > > > Message: 1 > > > > Date: Sun, 9 Jan 2022 10:25:39 +0100 > > > > From: "Robert Flosbach" r.flosbach at gmx.de > > > > To: gnupg-users at gnupg.org > > > > Subject: AW: GPG key generated on Windows... > > > > Message-ID: 003a01d8053a$de2469c0$9a6d3d40$@gmx.de > > > > Content-Type: text/plain; charset="UTF-8" > > > > Thank you very much for your help! > > > > For future reference and people having the same issue: gpg2.3 introduced a new packet type 20 which provides authenticated encryption with associated data (AEAD) [1]. A key generated with gpg2.3 supports this encryption type and encryption in Windows (using the current Gpg4win 4.0.0) defaults to AEAD for a key generated with default settings. Since AEAD/type 20 is not supported yet by version 2.2, decryption on linux distros is not possible using version 2.2.X from their repositories. > > > > [1] https://tools.ietf.org/id/draft-ietf-openpgp-rfc4880bis-06.html#rfc.section.5.16 > > > > Message: 2 > > > > Date: Sun, 09 Jan 2022 12:14:27 +0100 > > > > From: Werner Koch wk at gnupg.org > > > > To: Robert Flosbach via Gnupg-users gnupg-users at gnupg.org > > > > Subject: Re: AW: GPG key generated on Windows... > > > > Message-ID: 87h7adtb3g.fsf at wheatstone.g10code.de > > > > Content-Type: text/plain; charset="us-ascii" > > > > On Sun, 9 Jan 2022 10:25, Robert Flosbach said: > > > > > For future reference and people having the same issue: gpg2.3 > > > > > > introduced a new packet type 20 which provides authenticated > > > > > > encryption with associated data (AEAD) [1]. A key generated with > > > > > > gpg2.3 supports this encryption type and encryption in Windows (using > > > > > > the current Gpg4win 4.0.0) defaults to AEAD for a key generated with > > > > > > There are two ways to change this: the first is to change the > > > > > > preferences on your key (using 2.3's --edit-key) and the second is to > > > > > > put > > > > --8<---------------cut here---------------start------------->8--- > > > > ignore-invalid-option personal-aead-preferences > > > > personal-aead-preferences none > > > > --8<---------------cut here---------------end--------------->8--- > > > > into gpg.conf . From the man page: > > > > --personal-aead-preferences string > > > > Set the list of personal AEAD preferences to string. Use gpg > > --version to get a list of available algorithms, and use none to set > > no preference at all. This allows the user to safely override the > > algorithm chosen by the recipient key preferences, as GPG will only > > select an algorithm that is usable by all recipients. The most > > highly ranked cipher in this list is also used for the --symmetric > > encryption command. > > > > > > (the ignore-invalid-option line allows to use the same gpg.conf > > > > also with gpg 2.2) > > > > Shalom-Salam, > > > > Werner > > > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From bozho at kset.org Tue Jan 11 08:50:22 2022 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Tue, 11 Jan 2022 08:50:22 +0100 Subject: Yubikeys and GnuPG 2.2/2.3 In-Reply-To: <87leznspv5.fsf@wheatstone.g10code.de> References: <1b3ae727-ee8b-865b-ea6a-7ba6ab3dfae4@kset.org> <87leznspv5.fsf@wheatstone.g10code.de> Message-ID: On 10/01/2022 14:05, Werner Koch wrote: > On Fri, 7 Jan 2022 16:23, Marko Bo?ikovi? said: > >> My scdaemon.conf has a single line: >> >> card-timeout 1 > > Please remove this at least for testing. > >> log-file >> debug-level basic >> verbose > > Please change the > > debug-level ... > > to > > debug ipc,app,cardio > > Actually you should have seen a debug line "Yubikey: config=" due to the > verbose option. The "cardio" above returns all commands (so-called > APDUs) send to the card. This should help to reveal the problem. Just to confirm, my scdaemon.conf file should look like this: debug-level ipc,app,cardio verbose log-file >> 2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation >> (0x8010000b) > > Some other process is accessing the Yubikey. But as you already know > > pcsc-shared Yeah, but that one is available in 2.3. The card-timeout was suggested some time ago on Yubikey forums as a workaround for exclusive card access - and it worked for a while. If I 'primed' the card and got GnuPG to recognise it, it would work until the next machine reboot; it would still work even after sleep. Unfortunately, the probability of that working changed with each major Windows update :-) Is there a way in Windows to find which process is locking the card? I tried using Sysinternals Process Explorer to examine handles opened by scdaemon.exe while it does have access to Yubikey, but I couldn't find anything that would stand out... Thank you, -- Marko Bo?ikovi? From wk at gnupg.org Tue Jan 11 11:52:00 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Jan 2022 11:52:00 +0100 Subject: Gpg4win LetsEncrypt issue In-Reply-To: (Anze Jensterle's message of "Thu, 6 Jan 2022 15:33:10 +0100") References: <871r1lxo3x.fsf@wheatstone.g10code.de> <87wnjdued5.fsf@wheatstone.g10code.de> Message-ID: <87sftur1db.fsf@wheatstone.g10code.de> On Thu, 6 Jan 2022 15:33, Anze Jensterle said: > checked multiple times). Only deleting the old intermediates instead of the > root helped. Do you also check all the intermediate paths? Sure. My former answer was simply wrong. For details please see https://dev.gnupg.org/T5639 which was fixed with GnuPG 2.2.32 and 2.3.4. 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 Jan 11 19:25:30 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Jan 2022 19:25:30 +0100 Subject: Yubikeys and GnuPG 2.2/2.3 In-Reply-To: ("Marko =?utf-8?B?Qm/Fvmlrb3ZpxIc=?= via Gnupg-users"'s message of "Tue, 11 Jan 2022 08:50:22 +0100") References: <1b3ae727-ee8b-865b-ea6a-7ba6ab3dfae4@kset.org> <87leznspv5.fsf@wheatstone.g10code.de> Message-ID: <877db6p1t1.fsf@wheatstone.g10code.de> > Just to confirm, my scdaemon.conf file should look like this: > > debug-level ipc,app,cardio Replace that by debug ipc,app,cardio and remove debug-level lines. (The debug-leve thing is IMHO not very useful since we got those dedicated selectors. We should eventually remove the debug level thing and provide a GUI to select them.) 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 stefan.vasilev at posteo.ru Fri Jan 14 17:42:45 2022 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Fri, 14 Jan 2022 16:42:45 +0000 Subject: GnuPG - signed Telefax communication Message-ID: Hi all, If people have a modern Telefax machine, have you ever tried out to send a GnuPG signed Fax? I was thinking about the following: One prepares his message in the following way: ---begin message--- Message. --end message--- Then saves the message, detach signs it and converts the detached signature as QR-code which is put then also on the Fax document, while the receiver then OCR scans the document and decodes the QR-code. The --begin etc. markers should be used to detect where the OCR scanned document begins and ends to have later a good signature. Well, just a thought. Regards Stefan From andrewg at andrewg.com Fri Jan 14 18:40:28 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 14 Jan 2022 17:40:28 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: References: Message-ID: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> On Fri, 2022-01-14 at 16:42 +0000, ?????? ???????? via Gnupg-users wrote: > The --begin etc. markers should be used to detect where > the OCR scanned document begins and ends to have later > a good signature. If you are relying on OCR to reconstitute a bitwise-perfect message (because that's the only way a signature will validate) then you're asking for trouble, unless you're using a very restricted character set with at most one whitespace codepoint. > the receiver then OCR scans the document and decodes the QR-code If QR is an option, why not encode the entire message in QR? A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: This is a digitally signed message part URL: From vedaal at nym.hush.com Fri Jan 14 18:43:21 2022 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 14 Jan 2022 12:43:21 -0500 Subject: GnuPG - signed Telefax communication In-Reply-To: Message-ID: <20220114174322.0AF5480E2C2@smtp.hushmail.com> On 1/14/2022 at 11:46 AM, "?????? ???????? via Gnupg-users" wrote:Hi all, If people have a modern Telefax machine, have you ever tried out to send a GnuPG signed Fax? ===== You can simply armor sign the message. Don't bother with the 'begin' and 'end' part, it can be added on the receiving end. OCR it into telefax and send. I have never done this, and the few times I have tried similar things, the OCR always made mistakes. Anyone used an OCR program that reliably could get a page of gnupg block ciphertext Without mistakes -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.vasilev at posteo.ru Fri Jan 14 18:54:56 2022 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Fri, 14 Jan 2022 17:54:56 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> Message-ID: Andrew Gallagher wrote: > On Fri, 2022-01-14 at 16:42 +0000, ?????? ???????? via Gnupg-users > wrote: >> The --begin etc. markers should be used to detect where >> the OCR scanned document begins and ends to have later >> a good signature. > > If you are relying on OCR to reconstitute a bitwise-perfect message > (because that's the only way a signature will validate) then you're > asking for trouble, unless you're using a very restricted character set > with at most one whitespace codepoint. Maybe one could use a character, like a + or * etc., as whitespace. The idea is to use a Telefax machine for endpoint security, with an offline usage PC, which for example gpg4win is ideal for. >> the receiver then OCR scans the document and decodes the QR-code > > If QR is an option, why not encode the entire message in QR? I thought about that too, but in case the document would be several pages long and would not fit into a QR-code. Ok, one can split the large document and insert then several QR-codes into one Fax page. Regards Stefan From stefan.vasilev at posteo.ru Fri Jan 14 19:05:45 2022 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Fri, 14 Jan 2022 18:05:45 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: <20220114174322.0AF5480E2C2@smtp.hushmail.com> References: <20220114174322.0AF5480E2C2@smtp.hushmail.com> Message-ID: <9dcb0d57cfdeb06a9cffdf56455046d0@posteo.de> vedaal at nym.hush.com wrote: > On 1/14/2022 at 11:46 AM, "?????? ???????? via > Gnupg-users" wrote: > >> Hi all, >> >> If people have a modern Telefax machine, have you ever >> tried out to send a GnuPG signed Fax? >> >> ===== >> You can simply armor sign the message. >> Don't bother with the 'begin' and 'end' part, it can be added on the >> receiving end. >> OCR it into telefax and send. >> I have never done this, and the few times I have tried similar >> things, the OCR always made mistakes. >> >> Anyone used an OCR program that reliably could get a page of gnupg >> block ciphertext >> Without mistakes The only reliable OCR software I have found in the past was a Windows PC software, which gave 100 percent correct results. I used that for a scanned document, from a printed page. Maybe base32, for example, would be a good candidate, when used only with uppercase or only lowercase letters. http://www.boxoft.com/free-ocr/ Regards Stefan From andrewg at andrewg.com Fri Jan 14 19:09:24 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 14 Jan 2022 18:09:24 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> Message-ID: <942820b6-5424-6702-8361-3b1eedf13dbf@andrewg.com> On 14/01/2022 17:54, ?????? ???????? wrote: > > The idea is to use a Telefax machine for endpoint security, with > an offline usage PC, which for example gpg4win is ideal for. Would it not be simpler to use a modem? > I thought about that too, but in case the document would be several > pages long and would not fit into a QR-code. Ok, one can split the > large document and insert then several QR-codes into one Fax page. The largest standard QR code can hold just under 3kB of data in a single image. If you need more than that you would probably have to split across multiple sheets no matter what encoding system you choose. A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From stefan.vasilev at posteo.ru Fri Jan 14 19:22:50 2022 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Fri, 14 Jan 2022 18:22:50 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: <942820b6-5424-6702-8361-3b1eedf13dbf@andrewg.com> References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> <942820b6-5424-6702-8361-3b1eedf13dbf@andrewg.com> Message-ID: Andrew Gallagher wrote: > On 14/01/2022 17:54, ?????? ???????? wrote: >> >> The idea is to use a Telefax machine for endpoint security, with >> an offline usage PC, which for example gpg4win is ideal for. > > Would it not be simpler to use a modem? Good question. My thought was that Telefax is still used, among lawyers, doctors, business folks etc., and brand-new Fax machines can be bought on Amazon etc. >> I thought about that too, but in case the document would be several >> pages long and would not fit into a QR-code. Ok, one can split the >> large document and insert then several QR-codes into one Fax page. > > The largest standard QR code can hold just under 3kB of data in a > single > image. If you need more than that you would probably have to split > across multiple sheets no matter what encoding system you choose. Yes, do you know of any QR-code software (open source) which could do that task automatically, i.e. split a large (encoded) message into several QR-codes and reassemble later? Regards Stefan From andrewg at andrewg.com Fri Jan 14 19:33:44 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 14 Jan 2022 18:33:44 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> <942820b6-5424-6702-8361-3b1eedf13dbf@andrewg.com> Message-ID: <84a2ed9e-66f2-195f-5b14-e81fbd080504@andrewg.com> On 14/01/2022 18:22, ?????? ???????? wrote: >> Good question. My thought was that Telefax is still used, among > lawyers, doctors, business folks etc., and brand-new Fax machines > can be bought on Amazon etc. +1 for obsolescence! Beware of course that fax machines are VERY noisy, and analogue lines are increasingly routed over VOIP, so if you're using this as some kind of off-grid technique you're not going to get very far. > Yes, do you know of any QR-code software (open source) which could > do that task automatically, i.e. split a large (encoded) message into > several? QR-codes and reassemble later? I don't know about QR codes, but splitting a single file into multiple parts of a given size and reassembling them again can be done with the venerable unix utilities `split` and `cat`. A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From stefan.vasilev at posteo.ru Fri Jan 14 19:44:37 2022 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Fri, 14 Jan 2022 18:44:37 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: <84a2ed9e-66f2-195f-5b14-e81fbd080504@andrewg.com> References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> <942820b6-5424-6702-8361-3b1eedf13dbf@andrewg.com> <84a2ed9e-66f2-195f-5b14-e81fbd080504@andrewg.com> Message-ID: <9a94914ad19208faf384c93bb05c1276@posteo.de> Andrew Gallagher wrote: > On 14/01/2022 18:22, ?????? ???????? wrote: >>> Good question. My thought was that Telefax is still used, among >> lawyers, doctors, business folks etc., and brand-new Fax machines >> can be bought on Amazon etc. > > +1 for obsolescence! Beware of course that fax machines are VERY noisy, > and analogue lines are increasingly routed over VOIP, so if you're > using > this as some kind of off-grid technique you're not going to get very > far. Well, but what I personally like about using a Fax machine is, that you get a Fax report, can archive the Fax as a paper document, have in the Fax header your data defined and can use with GnuPG a free-form UID explicitly used for the Fax telephone number. And it is IMHO more decentralized and personal, compared to email usage, when signing up for an email service. And you don't need a MUA :-). >> Yes, do you know of any QR-code software (open source) which could >> do that task automatically, i.e. split a large (encoded) message into >> several? QR-codes and reassemble later? > > I don't know about QR codes, but splitting a single file into multiple > parts of a given size and reassembling them again can be done with the > venerable unix utilities `split` and `cat`. Ok, I have to check this out and as a Windows solution, because it is the most widely used OS. Maybe an idea for Werner and his commercial version of GnuPG Desktop. Regards Stefan From stuartl at longlandclan.id.au Fri Jan 14 21:33:43 2022 From: stuartl at longlandclan.id.au (Stuart Longland) Date: Sat, 15 Jan 2022 06:33:43 +1000 Subject: GnuPG - signed Telefax communication In-Reply-To: References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> Message-ID: <20220115063343.31010795@longlandclan.id.au> On Fri, 14 Jan 2022 17:54:56 +0000 ?????? ???????? via Gnupg-users wrote: > > If QR is an option, why not encode the entire message in QR? > > I thought about that too, but in case the document would be several > pages long and would not fit into a QR-code. Ok, one can split the > large document and insert then several QR-codes into one Fax page. I've experimented with using QR codes with OpenPGP on-and-off? mostly as a mechanism for sharing the public keys: the idea being that you could have business cards printed up with the back side containing a QR code of your public key (not a fingerprint, the actual key). In my experience, it is very hard to get the big and complex QR codes to scan reliably. Some of the QR codes used for COVID-19 contact tracing and vaccination status _really_ push the limits -- with those largish codes often failing to scan. ECC keys could be made small enough to have a snowflake's chance in hell of working. 4096-bit RSA was a no-go. There are schemes for encoding an image for printing onto a piece of paper and later scanning it back in to recover the original data. QR code is obviously a more recent option, but was not the first. These may be worth pursuing. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. From stefan.vasilev at posteo.ru Fri Jan 14 21:50:57 2022 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Fri, 14 Jan 2022 20:50:57 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: <20220115063343.31010795@longlandclan.id.au> References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> <20220115063343.31010795@longlandclan.id.au> Message-ID: <28fc774358b842c8d300b74a73111792@posteo.de> Stuart Longland wrote: > On Fri, 14 Jan 2022 17:54:56 +0000 > ?????? ???????? via Gnupg-users wrote: > >> > If QR is an option, why not encode the entire message in QR? >> >> I thought about that too, but in case the document would be several >> pages long and would not fit into a QR-code. Ok, one can split the >> large document and insert then several QR-codes into one Fax page. > > I've experimented with using QR codes with OpenPGP on-and-off? mostly > as a mechanism for sharing the public keys: the idea being that you > could have business cards printed up with the back side containing a QR > code of your public key (not a fingerprint, the actual key). > > In my experience, it is very hard to get the big and complex QR codes > to scan reliably. Some of the QR codes used for COVID-19 contact > tracing and vaccination status _really_ push the limits -- with those > largish codes often failing to scan. > > ECC keys could be made small enough to have a snowflake's chance in > hell of working. 4096-bit RSA was a no-go. Thanks for sharing your experience, much appreciated! > There are schemes for encoding an image for printing onto a piece of > paper and later scanning it back in to recover the original data. QR > code is obviously a more recent option, but was not the first. These > may be worth pursuing. Would you like to explain a bit such schemes? I am aware, for example, that GnuPG on a mini offline laptop can beat *all* smartphone crypto messenger, when it comes to endpoint security, when used with a dumb phone with a USB port and while sending GnuPG MMS messages. All users need for that is a software from GitHub, which can convert GnuPG messages to .png images and back. Simply search there for 'imgify'. Regards Stefan From stuartl at longlandclan.id.au Fri Jan 14 23:02:54 2022 From: stuartl at longlandclan.id.au (Stuart Longland) Date: Sat, 15 Jan 2022 08:02:54 +1000 Subject: GnuPG - signed Telefax communication In-Reply-To: <28fc774358b842c8d300b74a73111792@posteo.de> References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> <20220115063343.31010795@longlandclan.id.au> <28fc774358b842c8d300b74a73111792@posteo.de> Message-ID: <20220115080254.09a8ae1d@longlandclan.id.au> On Fri, 14 Jan 2022 20:50:57 +0000 ?????? ???????? wrote: > Stuart Longland wrote: > > > On Fri, 14 Jan 2022 17:54:56 +0000 > > ?????? ???????? via Gnupg-users wrote: > > > >> > If QR is an option, why not encode the entire message in QR? > >> > >> I thought about that too, but in case the document would be several > >> pages long and would not fit into a QR-code. Ok, one can split the > >> large document and insert then several QR-codes into one Fax page. > > > > I've experimented with using QR codes with OpenPGP on-and-off? mostly > > as a mechanism for sharing the public keys: the idea being that you > > could have business cards printed up with the back side containing a QR > > code of your public key (not a fingerprint, the actual key). > > > > In my experience, it is very hard to get the big and complex QR codes > > to scan reliably. Some of the QR codes used for COVID-19 contact > > tracing and vaccination status _really_ push the limits -- with those > > largish codes often failing to scan. > > > > ECC keys could be made small enough to have a snowflake's chance in > > hell of working. 4096-bit RSA was a no-go. > > Thanks for sharing your experience, much appreciated! > > > There are schemes for encoding an image for printing onto a piece of > > paper and later scanning it back in to recover the original data. QR > > code is obviously a more recent option, but was not the first. These > > may be worth pursuing. > > Would you like to explain a bit such schemes? I am aware, for example, > that GnuPG on a mini offline laptop can beat *all* smartphone crypto > messenger, when it comes to endpoint security, when used with a dumb > phone with a USB port and while sending GnuPG MMS messages. All > users need for that is a software from GitHub, which can convert GnuPG > messages to .png images and back. Simply search there for 'imgify'. https://github.com/dmshaw/paperkey/ is one such scheme, intended for making a private key back-up. It could probably be adapted to store arbitrary data. There may be others, I just can't put my finger on them now. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. From angel at pgp.16bits.net Fri Jan 14 23:14:38 2022 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 14 Jan 2022 23:14:38 +0100 Subject: GnuPG - signed Telefax communication In-Reply-To: References: Message-ID: <28c428714671ad822aa7959c54ccb35601ca9bf7.camel@16bits.net> On 2022-01-14 at 16:42 +0000, ?????? ???????? wrote: > Hi all, > > If people have a modern Telefax machine, have you ever > tried out to send a GnuPG signed Fax? > > I was thinking about the following: > > One prepares his message in the following way: > > ---begin message--- > > Message. > > --end message--- > > Then saves the message, detach signs it and converts the > detached signature as QR-code which is put then also on > the Fax document, while the receiver then OCR scans the > document and decodes the QR-code. What's wrong with simply using a PGP clearsign signature? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Mr ???????? I hereby send you this signed document with the information you requested: Gur nggnpx jvyy or ynhapurq ba fvkgu Whar Yours faithfully -----BEGIN PGP SIGNATURE----- iIcEARYIAC8WIQQCizm6L17e6dtQkgGnASDnmmvMqAUCYeH06xEcYW5nZWxAMTZi aXRzLm5ldAAKCRCnASDnmmvMqL6LAP9TIWvEqVFLAPbAZWqCegFvO2KEp/44ovJu XpE9FoZqiQD/U4Xz0ePZJNThyxzJuNwVyh8C2Iz3Kw3DFpYf3vF68Aw= =ZQiA -----END PGP SIGNATURE----- Of course, you need to properly OCR the signature, but you already need to properly OCR all the text anyway. (Hint: the final checksum may help). The font choice could be helpful in getting good OCR results as well. From stefan.vasilev at posteo.ru Fri Jan 14 23:32:49 2022 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Fri, 14 Jan 2022 22:32:49 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: <20220115080254.09a8ae1d@longlandclan.id.au> References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> <20220115063343.31010795@longlandclan.id.au> <28fc774358b842c8d300b74a73111792@posteo.de> <20220115080254.09a8ae1d@longlandclan.id.au> Message-ID: Stuart Longland wrote: > On Fri, 14 Jan 2022 20:50:57 +0000 > ?????? ???????? wrote: >> Would you like to explain a bit such schemes? I am aware, for example, >> that GnuPG on a mini offline laptop can beat *all* smartphone crypto >> messenger, when it comes to endpoint security, when used with a dumb >> phone with a USB port and while sending GnuPG MMS messages. All >> users need for that is a software from GitHub, which can convert GnuPG >> messages to .png images and back. Simply search there for 'imgify'. > > https://github.com/dmshaw/paperkey/ is one such scheme, intended for > making a private key back-up. It could probably be adapted to store > arbitrary data. > > There may be others, I just can't put my finger on them now. Ah ok, you referred to encoding key material. I just did a quick look and found this, which I may explore a little. http://ronja.twibright.com/optar/ Regards Stefan From stefan.vasilev at posteo.ru Fri Jan 14 23:39:50 2022 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Fri, 14 Jan 2022 22:39:50 +0000 Subject: GnuPG - signed Telefax communication In-Reply-To: <28c428714671ad822aa7959c54ccb35601ca9bf7.camel@16bits.net> References: <28c428714671ad822aa7959c54ccb35601ca9bf7.camel@16bits.net> Message-ID: ?ngel wrote: > On 2022-01-14 at 16:42 +0000, ?????? ???????? wrote: >> Hi all, >> >> If people have a modern Telefax machine, have you ever >> tried out to send a GnuPG signed Fax? >> >> I was thinking about the following: >> >> One prepares his message in the following way: >> >> ---begin message--- >> >> Message. >> >> --end message--- >> >> Then saves the message, detach signs it and converts the >> detached signature as QR-code which is put then also on >> the Fax document, while the receiver then OCR scans the >> document and decodes the QR-code. > > > What's wrong with simply using a PGP clearsign signature? I tried in the past to OCR scan armored GnuPG payloads, but it introduced errors in some characters. And in case this happens to others, how can users not having the original digital document correct then errors? If this works 100 percent reliable for you, you could explain the required (standard) settings for printed/scanned documents. Regards Stefan From stuartl at longlandclan.id.au Fri Jan 14 23:49:56 2022 From: stuartl at longlandclan.id.au (Stuart Longland) Date: Sat, 15 Jan 2022 08:49:56 +1000 Subject: GnuPG - signed Telefax communication In-Reply-To: References: <4eb5acf176ed02ef88fc2bd3fb2fc496d7008f64.camel@andrewg.com> <20220115063343.31010795@longlandclan.id.au> <28fc774358b842c8d300b74a73111792@posteo.de> <20220115080254.09a8ae1d@longlandclan.id.au> Message-ID: <20220115084956.7c4a7e8a@longlandclan.id.au> On Fri, 14 Jan 2022 22:32:49 +0000 ?????? ???????? wrote: > Ah ok, you referred to encoding key material. Not explicitly? as I said, you may be able to adapt that other project to store other things (e.g. the digitally signed documents discussed). > I just did a quick look and found this, which I may explore a little. > > http://ronja.twibright.com/optar/ That sounds like a better tool. I didn't quite manage to pull that up with my search queries before. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. From angel at pgp.16bits.net Sat Jan 15 00:10:38 2022 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 15 Jan 2022 00:10:38 +0100 Subject: GnuPG - signed Telefax communication In-Reply-To: References: <28c428714671ad822aa7959c54ccb35601ca9bf7.camel@16bits.net> Message-ID: On 2022-01-14 at 22:39 +0000, ?????? ???????? via Gnupg-users wrote: > > What's wrong with simply using a PGP clearsign signature? > > I tried in the past to OCR scan armored GnuPG payloads, but > it introduced errors in some characters. And in case this > happens to others, how can users not having the original digital > document correct then errors? > > If this works 100 percent reliable for you, you could explain the > required (standard) settings for printed/scanned documents. > > Regards > Stefan I don't claim it at all. I don't think I have even tried a scan + OCR in the last decade. However, without a proper text ocrring, you wouldn't be able to import the message content, either. Regards From rjh at sixdemonbag.org Mon Jan 17 00:09:16 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 16 Jan 2022 18:09:16 -0500 Subject: Side-channel attacks Message-ID: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> On this mailing list we sometimes see requests for help from people running dangerously antique versions of GnuPG. Wasn't all that long ago I was asked for help with something in the 1.2 series (!!). Without exception, our first response is usually "for the love of God, upgrade!" They rarely do. It's worked fine for them for a decade or more, and they're not going to change... On another mailing list I shared the story of how an AES256-encrypted drive was bypassed by law-enforcement and the plaintext recovered. The subject was using PGPdisk 6.0.2 on a Windows XP laptop, hibernated it, and the AES key was written to disk where a forensic examiner later picked it up. This didn't happen because of bugs in either PGPdisk or Windows XP: it was entirely due to the user ignoring Network Associates when they warned him, "PGPdisk 6.0.2 was never designed for Windows XP and you might be putting your data at risk by using it." Interested in the full story? The write-up is below. Not interested? Skip it, but please remember to upgrade your GnuPG installation at least every few years. :) ===== ===== ===== > Technically, your team didn't break (or crack) AES256, it > merely spotted the key (no small feat for sure!) (Long and nerdy. All of this history is off the top of my head, no notes. I may be in error in some places.) Depends on how one considers side channel attacks! It's true that we didn't successfully cryptanalyze the AES256 cipher, but we mounted a successful attack on a *correctly-implemented* AES256 system. (That "correctly-implemented" thing matters.) PGPdisk 6.5.8-CKT is a misnomer. Network Associates, Inc., stopped publishing PGPdisk source code after version 6.0.2. When NAI stopped publishing PGP source code in late 2000, a group of hacktivists, "Cyber-Knights Templar", led by a guy named Imad Faiad, took the last published source code for 6.5.8 and used it to build their own version, 6.5.8-CKT. When people asked them to also include PGPdisk, Faiad took the 6.0.2 PGPdisk source code, built PGPdisk 6.0.2, and included it in the 6.5.8-CKT package. Why does this matter? '01 was a very interesting year for home computing. That was the year Windows XP was released to home users. Prior home editions of Windows were fundamentally MS-DOS... MS-DOS pushed as far as it could humanly go, sure, but still MS-DOS. There are two big mistakes people make when discussing Windows 95: one is to think it was a graphical version of MS-DOS (it wasn't, it had genuine hard breaks from its MS-DOS heritage), and the other is to think it wasn't (it was, as evidenced by how it had to launch a new MS-DOS instance, at least briefly, for every program it ran, including native 32-bit Windows ones). Part of it being MS-DOS meant that pretty much every bit of hardware had its own specialized device driver. Yes, we had laptops in 1995-2001 that could hibernate when you closed the lid -- but only if you had a specialized device driver for your laptop (to make Windows aware of what to do), and good luck with application support for hibernation. Application developers couldn't be expected to support every device driver directly! This meant that PGPdisk 6.0.2 was *correctly written* for that era. It wasn't aware of hibernation events because, well, pretty much nothing was except Windows, and even then only with custom drivers loaded. Then in August of 2001, Microsoft switched the consumer version of Windows from MS-DOS to Windows NT. (Yes, every version of Windows from Windows 2000 onwards is actually Windows NT. And Windows NT is basically OpenVMS with the serial numbers filed off. Microsoft hired Dave Cutler to design "Windows New Technology", and Cutler was the chief architect of OpenVMS. Windows NT is basically a next-generation OpenVMS, the same way MacOS is a next-generation NeXTSTEP.) Anyway. We never saw *good* hibernation support in consumer grade hardware until Windows XP... released August of 2001. (Kinda true. Microsoft actually finally found a hackish way to do it tolerably well in Windows Me, in 1999. But since all of about four people worldwide bought Windows Me, we can discount this. Windows 2000 introduced good hibernation support, but that was a business-and-enterprise Windows version. Windows XP was when it became common in consumer-grade Windows.) Whew. I'm getting somewhere, I promise. So, post-XP, Microsoft had a standard, uniform way to do hibernation. The user signals a hibernation event, and Windows in turn blasts a message to each process saying "WE'RE CLOSING UP SHOP, WIPE ALL YOUR SENSITIVE STUFF." But that message wasn't standardized until Windows 2000! PGPdisk 6.0.2 was released in ... '98, I think? There's absolutely no way PGPdisk could have known about it. And so, when it received that notification, it does what every application does when it gets an advisory message it doesn't know what to do with: it shrugged its shoulders, said "meh", and kept going. ===== Why am I telling you this long story? Hell if I know. Let me re-read this and... Oh, right, that's where I'm going. ===== Some people hear my story of the downfall of Rajib Mitra and think "you guys exploited a bug in PGPdisk." We didn't. At no point did we find a bug in PGPdisk. PGPdisk was correctly implemented. But there's a reason why cryptographic software is only rated for certain environments, and why it's so important to take security nerds seriously when we caution, "that's very much not a recommended configuration..." The guys at Network Associates would tell anyone who asked, "if you plan on running this on Windows XP you really need to use PGP 7 or later, Microsoft made a ton of subtle changes to Windows, we can't guarantee earlier versions of PGP will work correctly, you could be putting your data at risk." Network Associates was very up-front about it. But a ton of their users said, "nah, that's just a ploy to sell more copies of PGP, why, I'm running PGPdisk 6.0.2 right now on my Windows XP system and it works just fine..." ===== We didn't break the AES256 cipher, nor did we find a bug in PGPdisk. We found a subtle conflict between the assumptions PGPdisk was making about its environment ("we don't need to worry about hibernation because there's no standard way to hibernate anyway") and the assumptions the environment was making about PGPdisk ("when I tell it we're hibernating, it will wipe sensitive data"). But it was one hell of a side channel attack, and it is unquestionably true to say that we found a technological means to gain access to a *correctly-implemented* AES256-encrypted drive. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From vedaal at nym.hush.com Mon Jan 17 02:55:19 2022 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Sun, 16 Jan 2022 20:55:19 -0500 Subject: Side-channel attacks In-Reply-To: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> Message-ID: <20220117015519.8452780E2CD@smtp.hushmail.com> On 1/16/2022 at 6:12 PM, "Robert J. Hansen via Gnupg-users" wrote:On this mailing list we sometimes see requests for help from people running dangerously antique versions of GnuPG. Wasn't all that long ago I was asked for help with something in the 1.2 series (!!). Without exception, our first response is usually "for the love of God, upgrade!" They rarely do. It's worked fine for them for a decade or more, and they're not going to change... ===== There is also the vulnerability of the 'shortcut' of decrypting symmetric encryption, and how that needed to be upgraded to versions where it was fixed. Vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From cryptoandrewbonham at hotmail.com Mon Jan 17 18:40:33 2022 From: cryptoandrewbonham at hotmail.com (Echi Hearthstone) Date: Mon, 17 Jan 2022 11:40:33 -0600 Subject: Upgrading Gpg4win Message-ID: Recently wanted to upgrade to the latest Gpg version on Windows 10 using installer,? and now is receiving an error in cmd "c:\>gpg -H gpg: Fatal: libgcrypt is too old (need 1.9.1, have 1.8.8)" Being more of a novices at this, how might I solve this issue, as I want to get into using this more often. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xD69C83098244DF6E.asc Type: application/pgp-keys Size: 2460 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Tue Jan 18 09:50:14 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 18 Jan 2022 09:50:14 +0100 Subject: Side-channel attacks In-Reply-To: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> Message-ID: On 17-01-2022 0:09, Robert J. Hansen via Gnupg-users wrote: > I was asked for help with something in the 1.2 series (!!).? Without > exception, our first response is usually "for the love of God, upgrade!" > > They rarely do.? It's worked fine for them for a decade or more, and > they're not going to change... Well, a bit more respect for backwards compatibility would help a lot by that. Now I'm forced to keep an 1.4 and pgp 2.6 version installed just to be able to read all my old data. Some people just refuse to update to versions that routinely break backwards compatibility. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Tue Jan 18 15:54:03 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 18 Jan 2022 09:54:03 -0500 Subject: Side-channel attacks In-Reply-To: References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> Message-ID: <8dd8c631-647d-55f8-a5a2-255db399c929@sixdemonbag.org> > Well, a bit more respect for backwards compatibility would help a lot > by that. Now I'm forced to keep an 1.4 and pgp 2.6 version installed > just to be able to read all my old data. Some people just refuse to > update to versions that routinely break backwards compatibility. You've had literally 27 years to migrate your data. I have zero sympathy. From gbernd at gmx.de Tue Jan 18 15:59:11 2022 From: gbernd at gmx.de (gbernd at gmx.de) Date: Tue, 18 Jan 2022 15:59:11 +0100 Subject: gpg --verify in batch mode / how to require a trust level? Message-ID: <9e2dc382-5ee8-1ae6-49bb-c4dc2d1b00e6@gmx.de> Hi, for a backup integrity protection, I want to add a signature check to the restore script to reject the backup files that are not properly signed. So far, so good. #$ gpg --verify backup.tar.sig #$ if [ $? -ne 0 ]; then echo "backup is not properly signed!"; exit 1; fi #$ tar xzvf backup.tar Now, I find that `gpg --verify` produces a return code rc=0 when there is a public key in my keyring that I once added, even though I never declared that I trust this key. How can I require `gpg --verify` to only accept keys from my keyring with a certain trust level and fail otherwise (rc!=0) Alternatively, how can I check that a signature was done with a specific key? Many thanks Bernd From wk at gnupg.org Tue Jan 18 16:40:44 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Jan 2022 16:40:44 +0100 Subject: Side-channel attacks In-Reply-To: (Johan Wevers via Gnupg-users's message of "Tue, 18 Jan 2022 09:50:14 +0100") References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> Message-ID: <877daxgigz.fsf@wheatstone.g10code.de> On Tue, 18 Jan 2022 09:50, Johan Wevers said: > Well, a bit more respect for backwards compatibility would help a lot by > that. Now I'm forced to keep an 1.4 and pgp 2.6 version installed just 1.4 should be able to decrypt all 2.6 generated data. 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 gbernd at gmx.de Tue Jan 18 16:19:27 2022 From: gbernd at gmx.de (gbernd at gmx.de) Date: Tue, 18 Jan 2022 16:19:27 +0100 Subject: gpg --verify in batch mode / how to require a trust level? Message-ID: Hi, for a backup integrity protection, I want to add a signature check to the restore script to reject the backup files that are not properly signed. So far, so good. #$ gpg --verify backup.tar.sig #$ if [ $? -ne 0 ]; then echo "backup is not properly signed!"; exit 1; fi #$ tar xzvf backup.tar Now, I find that `gpg --verify` produces a return code rc=0 when there is a public key in my keyring that I once added, even though I never declared that I trust this key. How can I require `gpg --verify` to only accept keys from my keyring with a certain trust level and fail otherwise (rc!=0) Alternatively, how can I check that a signature was done with a specific key? Many thanks Bern From rjh at sixdemonbag.org Tue Jan 18 17:23:56 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 18 Jan 2022 11:23:56 -0500 Subject: Side-channel attacks In-Reply-To: <877daxgigz.fsf@wheatstone.g10code.de> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> Message-ID: <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> > 1.4 should be able to decrypt all 2.6 generated data. Not from the Disastry builds, which extended 2.6 to support newer algorithms. From kloecker at kde.org Tue Jan 18 18:49:50 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 18 Jan 2022 18:49:50 +0100 Subject: gpg --verify in batch mode / how to require a trust level? In-Reply-To: <9e2dc382-5ee8-1ae6-49bb-c4dc2d1b00e6@gmx.de> References: <9e2dc382-5ee8-1ae6-49bb-c4dc2d1b00e6@gmx.de> Message-ID: <2580370.6VdgOfzBSv@daneel> On Dienstag, 18. Januar 2022 15:59:11 CET Bernd Graf via Gnupg-users wrote: > How can I require `gpg --verify` to only accept keys from my keyring > with a certain trust level and fail otherwise (rc!=0) > > Alternatively, how can I check that a signature was done with a specific > key? Use gpgv instead of gpg. It's much more lightweight and specifically meant for signature verification. In particular, you can pass it a keyring that only contains the keys you want: $ gpgv --keyring FILE backup.tar.sig backup.tar For details $ man gpgv Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Jan 18 19:39:46 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Jan 2022 19:39:46 +0100 Subject: gpg --verify in batch mode / how to require a trust level? In-Reply-To: <9e2dc382-5ee8-1ae6-49bb-c4dc2d1b00e6@gmx.de> (Bernd Graf via Gnupg-users's message of "Tue, 18 Jan 2022 15:59:11 +0100") References: <9e2dc382-5ee8-1ae6-49bb-c4dc2d1b00e6@gmx.de> Message-ID: <87zgnsga6l.fsf@wheatstone.g10code.de> On Tue, 18 Jan 2022 15:59, Bernd Graf said: > How can I require `gpg --verify` to only accept keys from my keyring > with a certain trust level and fail otherwise (rc!=0) Use gpgv instead of gpg. 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 stefan.vasilev at posteo.ru Tue Jan 18 20:20:56 2022 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Tue, 18 Jan 2022 19:20:56 +0000 Subject: Side-channel attacks In-Reply-To: References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> Message-ID: <127053587819fd6a135baaef42c10fff@posteo.de> Johan Wevers wrote: > On 17-01-2022 0:09, Robert J. Hansen via Gnupg-users wrote: > >> I was asked for help with something in the 1.2 series (!!).? Without >> exception, our first response is usually "for the love of God, >> upgrade!" >> >> They rarely do.? It's worked fine for them for a decade or more, and >> they're not going to change... > > Well, a bit more respect for backwards compatibility would help a lot > by > that. Now I'm forced to keep an 1.4 and pgp 2.6 version installed just > to be able to read all my old data. Some people just refuse to update > to > versions that routinely break backwards compatibility. I know from people that they use GnuPG 1.4 (Windows) for portability on a USB stick and therefore it could be run in a native Windows 10 sandbox, while also running a Tor hidden service in the sandbox, to communicate encrypted, without relying on third party client/server models via VPS or major email providers. Is it possible to do that with the latest gpg4win? Regards Stefan From vedaal at nym.hush.com Tue Jan 18 20:59:33 2022 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 18 Jan 2022 14:59:33 -0500 Subject: Side-channel attacks In-Reply-To: <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> Message-ID: <20220118195934.010EC8235E3@smtp.hushmail.com> On 1/18/2022 at 11:26 AM, "Robert J. Hansen via Gnupg-users" wrote:> 1.4 should be able to decrypt all 2.6 generated data. Not from the Disastry builds, which extended 2.6 to support newer algorithms. ===== 1.4 still can decrypt and verify anything in Disastry's last build. He died before he could implement Camellia. I have been using it since it came out, and 1.4 can easily decrypt and verify, but there is a simple procedural issue.: 1.4 decides that when it sees a v3 key, it tries to decrypt Idea and verify md5. Which works perfectly for 2.6.x. In order for 1.4 to decrypt and verify messages done with other encryption algorithms and signing algorithms, the name of the signing algorithm and the name of the encryption algorithm need to be included in the command line. If this is cumbersome, so just continue to use Disastry 2.6 to decrypt and verify. It's not gnupg's problem. Vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From petroh at safe-mail.net Wed Jan 19 15:33:35 2022 From: petroh at safe-mail.net (PetRoh) Date: Wed, 19 Jan 2022 07:33:35 -0700 Subject: pgp263iamulti06 In-Reply-To: <20220118195934.010EC8235E3@smtp.hushmail.com> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> Message-ID: I know those that still use pgp263iamulti06 [*] from removable media, without "installation". Are there known, documented security deficiencies in it? Any better alternative for those that need to use pgp/gpg in "portable" mode? --- * archive file pgp263iamulti06.zip, sha256sm: 35c39ed613a82c9aaf6463ef8c9a25d97cde592912fd3d6bd7efac2074cd783f From johanw at vulcan.xs4all.nl Thu Jan 20 21:22:43 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 20 Jan 2022 21:22:43 +0100 Subject: Side-channel attacks In-Reply-To: <8dd8c631-647d-55f8-a5a2-255db399c929@sixdemonbag.org> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <8dd8c631-647d-55f8-a5a2-255db399c929@sixdemonbag.org> Message-ID: <1fa62085-bb38-4b13-6f44-5dce60e16887@vulcan.xs4all.nl> On 18-01-2022 15:54, Robert J. Hansen via Gnupg-users wrote: >> Well, a bit more respect for backwards compatibility would help a lot >> by that. Now I'm forced to keep an 1.4 and pgp 2.6 version installed >> just to be able to read all my old data. Some people just refuse to >> update to versions that routinely break backwards compatibility. > > You've had literally 27 years to migrate your data.? I have zero sympathy. Migrate? That data is in my mail archive. While it would be possible for me to write a program to scan the mail file for pgp blockes, check which pgp version is used, decrypt the data, re-encrypt it with a modern gpg version and replace that textblock, it would still lose information about dates and signatures. Those who are confined to mail clients that use binary file formats (read: Outlook) don't have that option unless you know a way to do that in .pst files. How I can do that with mail located at my provider, who probably does not give me write access to the raw mailbox file, is also a mystery to me. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From johanw at vulcan.xs4all.nl Thu Jan 20 21:26:35 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 20 Jan 2022 21:26:35 +0100 Subject: Side-channel attacks In-Reply-To: <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> Message-ID: On 18-01-2022 17:23, Robert J. Hansen via Gnupg-users wrote: >> 1.4 should be able to decrypt all 2.6 generated data. > > Not from the Disastry builds, which extended 2.6 to support newer > algorithms. Lucky for me I never use that version, as I never respected the copyright of the RSA and IDEA algorithms (questionable in Europe anyway). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Fri Jan 21 07:05:55 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 21 Jan 2022 01:05:55 -0500 Subject: Side-channel attacks In-Reply-To: <1fa62085-bb38-4b13-6f44-5dce60e16887@vulcan.xs4all.nl> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <8dd8c631-647d-55f8-a5a2-255db399c929@sixdemonbag.org> <1fa62085-bb38-4b13-6f44-5dce60e16887@vulcan.xs4all.nl> Message-ID: > Migrate? That data is in my mail archive. While it would be possible for > me to write a program to scan the mail file for pgp blockes, check which > pgp version is used, decrypt the data, re-encrypt it with a modern gpg > version and replace that textblock, it would still lose information > about dates and signatures. No, and that entire line of argument is disingenuous. You use PGP 2.6 to decrypt/verify each message. You verify the signature to whatever degree you feel is necessary, and write an attestation: "On January 21 at 12:56am I successfully decrypted this message with hash value X and verified the PGP 2.6 signature as belonging to Y. I then re-encrypted it to myself, and that ciphertext has hash value Z." Sign the attestation. You re-encrypt the plaintext to your current OpenPGP certificate. You attach (via PGP/MIME) the PGP 2.6 ciphertext and your attestation. Presto. You now have encrypted text you can use with GnuPG 2.3. If you need to verify the document you can verify the signature on the attestation. If the signature is good, clearly no one has tampered with your declaration. To do a more rigorous verification you can check the hash values of the ciphertexts. To do a most-rigorous verification you can run PGP 2.6.3 on the original attachment. We've known how to do this for at least a quarter-century, Johan. 25 years. Twenty. Five. *Years*. Now, it's true that hardly anyone does this, and there's not exactly much demand for tools that do this. That is, I'm convinced, because in the real world, there's nobody who needs to do this. I repeat: if you really needed this functionality, you've had a quarter-century to do something about it, a quarter-century where we've known what to do about it. If you're not migrating, that's on you. From rjh at sixdemonbag.org Fri Jan 21 07:06:35 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 21 Jan 2022 01:06:35 -0500 Subject: Side-channel attacks In-Reply-To: References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> Message-ID: > Lucky for me I never use that version, as I never respected the > copyright of the RSA and IDEA algorithms (questionable in Europe anyway). Patents, not copyrights. From mihaidavid at posteo.net Sat Jan 22 19:18:56 2022 From: mihaidavid at posteo.net (Horia Mihai David) Date: Sat, 22 Jan 2022 18:18:56 +0000 Subject: Short question regarding config Message-ID: Hi all, What's the difference between `|--personal-cipher-preferences' and `default-preference-list'?| |What ends up in the exported keys? | | | |Thanks!| |- Mihai | From mihaidavid at posteo.net Sat Jan 22 19:19:55 2022 From: mihaidavid at posteo.net (Horia Mihai David) Date: Sat, 22 Jan 2022 18:19:55 +0000 Subject: Short question regarding config In-Reply-To: References: Message-ID: Sorry for the formatting errors. Regards, - Mihai From rjh at sixdemonbag.org Sat Jan 22 20:59:00 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 22 Jan 2022 14:59:00 -0500 Subject: Short question regarding config In-Reply-To: References: Message-ID: <5dc7516c-fc97-fca6-6739-33cf64c0ff11@sixdemonbag.org> > What's the difference between `|--personal-cipher-preferences' and > `default-preference-list'?| The former is your preferences for the traffic you generate. The latter is your advertised list of preferences that are affixed to new certificates you generate. E.g.: if you have p-c-p of CAMELLIA256, TWOFISH, AES256, you will use Camellia if your recipient supports it, Twofish if your recipient supports it but not Camellia, AES256 if your recipient supports it but neither Camellia nor Twofish, and if your recipient supports none of them you'll use 3DES (which all recipients support). If your d-p-l reads AES256, CAMELLIA256, TWOFISH, then any new certificate you generate will have a note on it telling people "I can read traffic encrypted with any of those algorithms." 99% of users will never have any need to use these options. From rjh at sixdemonbag.org Sun Jan 23 02:47:41 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 22 Jan 2022 20:47:41 -0500 Subject: pgp263iamulti06 In-Reply-To: References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> Message-ID: > Are there known, documented security deficiencies in it? The CSPRNG is almost certainly broken. PGP 2.6.3 was a DOS program, which meant it could easily get direct access to hardware. That meant it could use the uncertainty of the physical world as a key factor in the CSPRNG. But ever since August 2001 and the release of Windows XP, DOS programs no longer get direct access to hardware. Everything is abstracted away through the Windows Hardware Abstraction Layer (HAL) or other similar layers. The core assumption of the PGP 2.6.3 CSPRNG ("we can use direct access to hardware to sample entropy from the physical world") no longer holds and hasn't been valid for more than twenty years. From petroh at safe-mail.net Sun Jan 23 18:34:22 2022 From: petroh at safe-mail.net (PetRoh) Date: Sun, 23 Jan 2022 10:34:22 -0700 Subject: pgp263iamulti06 In-Reply-To: References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> Message-ID: <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> > from rjh at sixdemonbag.org...: > The CSPRNG is almost certainly broken. Thank you! When generating the key-pair with Re: pgp263iamulti06, the "randomness" is obtained by user's keyboard input. Is it then that the above applies only when the session key is generated? > PGP 2.6.3 was a DOS program,... And Linux. (Apple too - remember compiling it on Mac when the command-line build tools were still available). So is the same (i.e., a problematic source of randomness when generating the session key) likely to be the case compiling/running 2.6.3iamulti06 under Linux today? PetRoh From rjh at sixdemonbag.org Sun Jan 23 21:23:51 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 23 Jan 2022 15:23:51 -0500 Subject: pgp263iamulti06 In-Reply-To: <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> Message-ID: <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> > When generating the key-pair with Re: pgp263iamulti06, the > "randomness" is obtained by user's keyboard input. Is it > then that the above applies only when the session key is > generated? No, the whole CSPRNG is (probably) compromised. PGP 2.6.3 used keyboard interrupts harvested directly from the hardware to get a collection of random bits which it then fed into the CSPRNG to be expanded out into a large quantity of randomish bits. It's just that when generating a new certificate it always replenished the CSPRNG's entropy -- when generating traffic it didn't, but the CSPRNG was still dependent on the randomness collected earlier. On Windows, you no longer have this direct access to hardware and there's almost certainly some determinism introduced by the HAL. > the command-line build tools were still available). So is > the same (i.e., a problematic source of randomness when > generating the session key) likely to be the case > compiling/running 2.6.3iamulti06 under Linux today? I wouldn't say "almost definitely" the way I do for DOS, but I'd still say I'd find it a disturbing possibility I'd want to investigate and rule out before I used PGP 2.6.3 in a UNIX environment. From johanw at vulcan.xs4all.nl Sun Jan 23 23:49:43 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 23 Jan 2022 23:49:43 +0100 Subject: pgp263iamulti06 In-Reply-To: <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> Message-ID: <6d225f06-dbe4-50be-d2ad-44b5e3ba4616@vulcan.xs4all.nl> On 23-01-2022 21:23, Robert J. Hansen via Gnupg-users wrote: > No, the whole CSPRNG is (probably) compromised.? PGP 2.6.3 used keyboard > interrupts harvested directly from the hardware to get a collection of > random bits which it then fed into the CSPRNG to be expanded out into a > large quantity of randomish bits. Is this also used when generating symmetric keys? Or only used by secret key generation? If the last is the case, then existing keys generated on DOS (or Linux?) might be safe (apart from a possibly short key length). BTW, I remember I compiled 2.6.3ia with Visual Studio 5 on windows 95 and that was easy (just put all C files in a new project and build it). The added advantage was that I got long filename support without any code changes. I assume that it would work the same for the multi versions although I never tried, none of my contacts used those. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Mon Jan 24 05:26:07 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 23 Jan 2022 23:26:07 -0500 Subject: pgp263iamulti06 In-Reply-To: <6d225f06-dbe4-50be-d2ad-44b5e3ba4616@vulcan.xs4all.nl> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> <6d225f06-dbe4-50be-d2ad-44b5e3ba4616@vulcan.xs4all.nl> Message-ID: <7ed1d6fe-ced9-b800-b8bd-038f04fa44e5@sixdemonbag.org> > Is this also used when generating symmetric keys? Or only used by secret > key generation? If the last is the case, then existing keys generated on > DOS (or Linux?) might be safe (apart from a possibly short key length). Existing certificates would be unaffected, but since the CSPRNG is used for all sorts of things in signatures and encryption, it absolutely should not be used for anything more than reading old traffic. From rjh at sixdemonbag.org Mon Jan 24 05:29:32 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 23 Jan 2022 23:29:32 -0500 Subject: pgp263iamulti06 In-Reply-To: <61EE1F44.7000803@gmail.com> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> <61EE1F44.7000803@gmail.com> Message-ID: <21c8a322-c2c3-63a7-83dd-dd6f31fa3da0@sixdemonbag.org> > I remember using a Windows-95-native PGP years ago that also used > keyboard and mouse events to acquire entropy; presumably, there was not > that much determinism, or every PGP key generated on Windows is likely > to be weak. Win95 still allowed direct access to underlying hardware. In the XP-and-beyond world, direct hardware access virtually requires a driver. > If it reads /dev/random, you are fine; the Linux kernel collects very > good entropy and GPG uses (and has always used) that source.? If it does > something else, you probably have a problem, possibly a "Debian OpenSSL" > problem... /dev/random didn't exist in 1991-2 when PGP 2.6.3i was written. At least on SGI IRIX, the standard way of getting random bytes was to open an audio device and sample the least significant bits of the input stream... From jcb62281 at gmail.com Mon Jan 24 04:38:44 2022 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 23 Jan 2022 21:38:44 -0600 Subject: pgp263iamulti06 In-Reply-To: <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> Message-ID: <61EE1F44.7000803@gmail.com> Robert J. Hansen via Gnupg-users wrote: >> When generating the key-pair with Re: pgp263iamulti06, the >> "randomness" is obtained by user's keyboard input. Is it >> then that the above applies only when the session key is >> generated? > > No, the whole CSPRNG is (probably) compromised. PGP 2.6.3 used > keyboard interrupts harvested directly from the hardware to get a > collection of random bits which it then fed into the CSPRNG to be > expanded out into a large quantity of randomish bits. It's just that > when generating a new certificate it always replenished the CSPRNG's > entropy -- when generating traffic it didn't, but the CSPRNG was still > dependent on the randomness collected earlier. > > On Windows, you no longer have this direct access to hardware and > there's almost certainly some determinism introduced by the HAL. I remember using a Windows-95-native PGP years ago that also used keyboard and mouse events to acquire entropy; presumably, there was not that much determinism, or every PGP key generated on Windows is likely to be weak. >> the command-line build tools were still available). So is >> the same (i.e., a problematic source of randomness when >> generating the session key) likely to be the case >> compiling/running 2.6.3iamulti06 under Linux today? > > I wouldn't say "almost definitely" the way I do for DOS, but I'd still > say I'd find it a disturbing possibility I'd want to investigate and > rule out before I used PGP 2.6.3 in a UNIX environment. If it reads /dev/random, you are fine; the Linux kernel collects very good entropy and GPG uses (and has always used) that source. If it does something else, you probably have a problem, possibly a "Debian OpenSSL" problem... -- Jacob From petroh at safe-mail.net Mon Jan 24 00:26:18 2022 From: petroh at safe-mail.net (PetRoh) Date: Sun, 23 Jan 2022 16:26:18 -0700 Subject: pgp263iamulti06 In-Reply-To: <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> Message-ID: <247c9e16-170e-0b1c-36cc-d783cb5fd7b1@safe-mail.net> > from rjh at sixdemonbag.org...: ... > I wouldn't say "almost definitely" the way I do for DOS, but I'd still > say I'd find it a disturbing possibility I'd want to investigate and > rule out before I used PGP 2.6.3 in a UNIX environment. Thank you very much for your comments. Would you be able to suggest the version to use in "portable" mode? (a) under Linux? (b) under Windows? tia, PetRoh From arjunkc at gmail.com Mon Jan 24 03:12:34 2022 From: arjunkc at gmail.com (Arjun) Date: Sun, 23 Jan 2022 21:12:34 -0500 Subject: Help getting gtk or qt pinentry dialog forwarded over ssh connection Message-ID: <164299035499.3257.5035097555244963249@mediaserver.home> Hi I have a very basic gnupg setup on a remote server, with the following options set for the gpg-agent. Please cc me on the replies since I have not subscribed. #pinentry-program /usr/bin/pinentry-curses #pinentry-program /usr/bin/pinentry-tty #pinentry-program /usr/bin/pinentry-qt #pinentry-program /usr/bin/pinentry-x11 #pinentry-program /usr/bin/pinentry-gnome3 # i have tried all the above pinentry programs pinentry-program /usr/bin/pinentry-gtk-2 allow-loopback-pinentry default-cache-ttl 14400 max-cache-ttl 14400 debug-pinentry debug-level 1024 I have GPG_TTY=$(tty) set in my .bashrc. However, when I ssh in ssh remote gpg-connect-agent updatestartuptty /bye gpg --decrypt I always get a curses pinentry. My gnupg is version 2.2.12 on debian buster. Here is my log. https://pastebin.com/APTRTJ5c DBG: chan_9 -> OK Pleased to meet you, process 15072 DBG: chan_9 <- RESET DBG: chan_9 -> OK DBG: chan_9 <- OPTION ttyname=/dev/pts/1 DBG: chan_9 -> OK DBG: chan_9 <- OPTION ttytype=xterm-256color DBG: chan_9 -> OK DBG: chan_9 <- OPTION display=localhost:11.0 DBG: chan_9 -> OK DBG: chan_9 <- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/b us DBG: chan_9 -> OK DBG: chan_9 <- OPTION lc-ctype=en_US.UTF-8 DBG: chan_9 -> OK DBG: chan_9 <- OPTION lc-messages=en_US.UTF-8 DBG: chan_9 -> OK DBG: chan_9 <- GETINFO version DBG: chan_9 -> D 2.2.12 DBG: chan_9 -> OK DBG: chan_9 <- OPTION allow-pinentry-notify DBG: chan_9 -> OK DBG: chan_9 <- OPTION agent-awareness=2.1.0 DBG: chan_9 -> OK DBG: chan_9 <- HAVEKEY DBG: chan_9 -> OK DBG: chan_9 <- SETKEY DBG: chan_9 -> OK DBG: chan_9 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secr et+key: DBG: chan_9 -> OK DBG: chan_9 <- PKDECRYPT DBG: chan_9 -> S INQUIRE_MAXLEN 4096 DBG: chan_9 -> INQUIRE CIPHERTEXT DBG: chan_9 <- [ redacted ] DBG: chan_9 <- END DBG: keygrip: redacted DBG: cipher: redacted DBG: DBG: sed for 30m) DBG: DBG: ed cache key) ... DBG: Jan 23 21:03:04 mediaserver gpg-agent[15798]: starting a new PIN Entry DBG: chan_11 <- OK Pleased to meet you, process 15798 DBG: connection to PIN entry established DBG: chan_11 -> OPTION no-grab DBG: chan_11 <- OK DBG: chan_11 -> OPTION ttyname=/dev/pts/1 DBG: chan_11 <- OK DBG: chan_11 -> OPTION ttytype=xterm-256color DBG: chan_11 <- OK DBG: chan_11 -> OPTION lc-ctype=en_US.UTF-8 DBG: chan_11 <- OK DBG: chan_11 -> OPTION lc-messages=en_US.UTF-8 DBG: chan_11 <- OK DBG: chan_11 -> OPTION allow-external-password-cache DBG: chan_11 <- OK Pleased to meet you, process 15798 DBG: connection to PIN entry established DBG: chan_11 -> OPTION no-grab DBG: chan_11 <- OK DBG: chan_11 -> OPTION ttyname=/dev/pts/1 DBG: chan_11 <- OK DBG: chan_11 -> OPTION ttytype=xterm-256color DBG: chan_11 <- OK DBG: chan_11 -> OPTION lc-ctype=en_US.UTF-8 DBG: chan_11 <- OK DBG: chan_11 -> OPTION lc-messages=en_US.UTF-8 DBG: chan_11 <- OK DBG: chan_11 -> OPTION allow-external-password-cache DBG: chan_11 <- OK DBG: chan_11 -> OPTION default-ok=_OK DBG: chan_11 <- OK DBG: chan_11 -> OPTION default-cancel=_Cancel DBG: chan_11 <- OK DBG: chan_11 -> OPTION default-yes=_Yes DBG: chan_11 <- ERR 83886254 Unknown option DBG: chan_11 -> OPTION default-no=_No DBG: chan_11 <- ERR 83886254 Unknown option DBG: chan_11 -> OPTION default-prompt=PIN: DBG: chan_11 <- OK DBG: chan_11 -> OPTION default-pwmngr=_Save in password manager DBG: chan_11 <- OK DBG: chan_11 -> OPTION default-cf-visi=Do you really want to make your passphrase visible on the screen? DBG: chan_11 <- OK DBG: chan_11 -> OPTION default-tt-visi=Make passphrase visible DBG: chan_11 <- OK DBG: chan_11 -> OPTION default-tt-hide=Hide passphrase DBG: chan_11 <- OK DBG: chan_11 -> OPTION touch-file=/run/user/1000/gnupg/S.gpg-agent DBG: chan_11 <- OK DBG: chan_11 -> OPTION owner=15072 mediaserver DBG: chan_11 <- OK DBG: chan_11 -> GETINFO flavor DBG: chan_11 <- D gtk2:curses DBG: chan_11 <- OK DBG: chan_11 -> GETINFO version DBG: chan_11 <- D 1.1.0 DBG: chan_11 <- OK DBG: chan_11 -> GETINFO ttyinfo DBG: chan_11 <- D /dev/pts/1 xterm-256color - DBG: chan_11 <- OK DBG: chan_11 -> GETINFO pid DBG: chan_11 <- D 15074 DBG: chan_11 <- OK DBG: chan_9 -> INQUIRE PINENTRY_LAUNCHED 15074 gtk2:curses 1.1.0 /dev/pts/1 xterm-256color - DBG: chan_9 <- END Arjun From rjh at sixdemonbag.org Mon Jan 24 16:02:54 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 24 Jan 2022 10:02:54 -0500 Subject: pgp263iamulti06 In-Reply-To: <247c9e16-170e-0b1c-36cc-d783cb5fd7b1@safe-mail.net> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> <247c9e16-170e-0b1c-36cc-d783cb5fd7b1@safe-mail.net> Message-ID: > Would you be able to suggest the version to use in "portable" mode? GnuPG 1.4, but I'd honestly prefer to run a bootable Linux distro. Portable apps are a monstrous security hazard if they're used on computers beyond your control. USB malware is a very real thing. From wk at gnupg.org Mon Jan 24 18:19:09 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Jan 2022 18:19:09 +0100 Subject: Help getting gtk or qt pinentry dialog forwarded over ssh connection In-Reply-To: <164299035499.3257.5035097555244963249@mediaserver.home> (Arjun via Gnupg-users's message of "Sun, 23 Jan 2022 21:12:34 -0500") References: <164299035499.3257.5035097555244963249@mediaserver.home> Message-ID: <87lez56ohe.fsf@wheatstone.g10code.de> On Sun, 23 Jan 2022 21:12, Arjun said: > I have GPG_TTY=$(tty) set in my .bashrc. However, when I ssh in > > ssh remote By default ssh does not allow X forwarding. You need to use an extra option to ssh to allow X programs on the remote to work on your (local) X-server. A quick test is to run "xfd" If it runs and tells you no "no font to display" you can run X programs (like pinentry-gtk) on the remote box. If you do not fully trust the remote machine (and only then you should use X forwarding), you may still use gpg/gpgsm on the remote box: See https://wiki.gnupg.org/AgentForwarding 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 arjunkc at gmail.com Mon Jan 24 22:17:40 2022 From: arjunkc at gmail.com (Arjun) Date: Mon, 24 Jan 2022 16:17:40 -0500 Subject: Help getting gtk or qt pinentry dialog forwarded over ssh connection In-Reply-To: <87lez56ohe.fsf@wheatstone.g10code.de> References: <164299035499.3257.5035097555244963249@mediaserver.home> <87lez56ohe.fsf@wheatstone.g10code.de> Message-ID: <164305906033.15742.1838446547448662407@mediaserver.home> Hi Werner I do know that I need to enable ssh X11 forwarding, and have tested it with ForwardX11 and ForwardX11Trusted on (-X and -Y on the command line). Unfortunately, pin entry always defaults to tty. I fully trust the machine (it's mine). xfd does say "no font to display". In fact, if I ssh in, and run /usr/bin/pinentry-gtk-2 getpin I do get an X11 window to type my pin into. When I type in getinfo ttyinfo it does say "gtk-2". However, the logs I attached say that when I run gpg --decrypt ... The GETINFO flavor command on pinentry gives gtk2:curses This is the reason I'm seeing a curses pinentry when I try to gpg --decrypt something. I don't know how to get my gpg-agent to give me an X11 pinentry. Best Arjun Quoting Werner Koch (2022-01-24 12:19:09) > On Sun, 23 Jan 2022 21:12, Arjun said: > > > I have GPG_TTY=$(tty) set in my .bashrc. However, when I ssh in > > > > ssh remote > > By default ssh does not allow X forwarding. You need to use an extra > option to ssh to allow X programs on the remote to work on your (local) > X-server. > > A quick test is to run "xfd" If it runs and tells you no "no font to > display" you can run X programs (like pinentry-gtk) on the remote box. > > If you do not fully trust the remote machine (and only then you should > use X forwarding), you may still use gpg/gpgsm on the remote box: See > > https://wiki.gnupg.org/AgentForwarding > > > Salam-Shalom, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mogens-jensen at protonmail.com Wed Jan 26 09:15:30 2022 From: mogens-jensen at protonmail.com (Mogens Jensen) Date: Wed, 26 Jan 2022 08:15:30 +0000 Subject: Backup of GPG private keys? Message-ID: As of GnuPG (LTS) version 2.2.33, what is the recommended way to backup your GPG private keys on a Linux system? 1. Backing up the entire ~./gnupg directory? 2. Exporting only the keys? $ gpg --armor --export-secret-keys >gpg-key-backup.asc Thanks. From wk at gnupg.org Wed Jan 26 16:14:11 2022 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Jan 2022 16:14:11 +0100 Subject: Backup of GPG private keys? In-Reply-To: (Mogens Jensen via Gnupg-users's message of "Wed, 26 Jan 2022 08:15:30 +0000") References: Message-ID: <87mtjiil6k.fsf@wheatstone.g10code.de> On Wed, 26 Jan 2022 08:15, Mogens Jensen said: > As of GnuPG (LTS) version 2.2.33, what is the recommended way to backup > your GPG private keys on a Linux system? For just the private keys you can tar up the private-keys-v1.d directory, encrypt it with gpg (you might want to use a password (-c) then). But such a backup has no public keys and they can't be re-generated from the backup-ed private keys. However, the other data below ~/.gnupg is not highly sensitive can can be part of the regular backup. > 1. Backing up the entire ~./gnupg directory? That is of course a working option but recall that the data has the private keys and you should encrypt it. > 2. Exporting only the keys? > > $ gpg --armor --export-secret-keys >gpg-key-backup.asc That is possible, but, frankly, the OpenPGP format for encrypted private keys is not as strong as it should be - thus you better add an additional encryption layer. The actual problem here is that you need to provide the passphrase for each 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 Wed Jan 26 16:14:11 2022 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Jan 2022 16:14:11 +0100 Subject: Backup of GPG private keys? In-Reply-To: (Mogens Jensen via Gnupg-users's message of "Wed, 26 Jan 2022 08:15:30 +0000") References: Message-ID: <87mtjiil6k.fsf@wheatstone.g10code.de> On Wed, 26 Jan 2022 08:15, Mogens Jensen said: > As of GnuPG (LTS) version 2.2.33, what is the recommended way to backup > your GPG private keys on a Linux system? For just the private keys you can tar up the private-keys-v1.d directory, encrypt it with gpg (you might want to use a password (-c) then). But such a backup has no public keys and they can't be re-generated from the backup-ed private keys. However, the other data below ~/.gnupg is not highly sensitive can can be part of the regular backup. > 1. Backing up the entire ~./gnupg directory? That is of course a working option but recall that the data has the private keys and you should encrypt it. > 2. Exporting only the keys? > > $ gpg --armor --export-secret-keys >gpg-key-backup.asc That is possible, but, frankly, the OpenPGP format for encrypted private keys is not as strong as it should be - thus you better add an additional encryption layer. The actual problem here is that you need to provide the passphrase for each 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From max-julian at qyanu.net Wed Jan 26 18:01:17 2022 From: max-julian at qyanu.net (Max-Julian Pogner) Date: Wed, 26 Jan 2022 18:01:17 +0100 Subject: Backup of GPG private keys? In-Reply-To: <87mtjiil6k.fsf@wheatstone.g10code.de> References: <87mtjiil6k.fsf@wheatstone.g10code.de> Message-ID: <55f5e937-7b56-6e20-1798-ab94f2b2d4da@qyanu.net> On 26/01/2022 16:14, Werner Koch via Gnupg-users wrote: > On Wed, 26 Jan 2022 08:15, Mogens Jensen said: >> 1. Backing up the entire ~./gnupg directory? > > That is of course a working option but recall that the data has the > private keys and you should encrypt it. If i may interject, arn't the private keys already stored encrypted[1] on disk? The first encryption ought to be already secure enough. allthebest, Max [1] even encrypted by the same program, gnupg; so if there is an encryption flaw inside it, encrypting the data with the same program again wouldn't help. From steffen at sdaoden.eu Wed Jan 26 21:45:03 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 26 Jan 2022 21:45:03 +0100 Subject: Backup of GPG private keys? In-Reply-To: <87mtjiil6k.fsf@wheatstone.g10code.de> References: <87mtjiil6k.fsf@wheatstone.g10code.de> Message-ID: <20220126204503.EZeui%steffen@sdaoden.eu> Werner Koch via Gnupg-users wrote in <87mtjiil6k.fsf at wheatstone.g10code.de>: |On Wed, 26 Jan 2022 08:15, Mogens Jensen said: |> As of GnuPG (LTS) version 2.2.33, what is the recommended way to backup |> your GPG private keys on a Linux system? | |For just the private keys you can tar up the private-keys-v1.d |directory, encrypt it with gpg (you might want to use a password (-c) |then). But such a backup has no public keys and they can't be |re-generated from the backup-ed private keys. However, the other data |below ~/.gnupg is not highly sensitive can can be part of the regular |backup. | |> 1. Backing up the entire ~./gnupg directory? | |That is of course a working option but recall that the data has the |private keys and you should encrypt it. | |> 2. Exporting only the keys? |> |> $ gpg --armor --export-secret-keys >gpg-key-backup.asc | |That is possible, but, frankly, the OpenPGP format for encrypted private |keys is not as strong as it should be - thus you better add an |additional encryption layer. The actual problem here is that you need |to provide the passphrase for each key. And there is this neat trick with the removed private master key, in a file headlined "subkey howto" somewhere on a Debian server. This is how i do it --- i even use three different PGP home directories, ~/sic/.pgp on an always unmounted encfs volume, that has the private master key, and on a mounted-as-long-as-LID-is-up ~/sec.arena/pgp{,-nosecrets}.git encfs volume (all residing on a LUKS partition): #@ ~/.gnupg/gpg.conf a.k.a ~/sec.arena/pgp.git/gpg.conf #@ For GPG v1. #@ This contains a secring with a mutilated private key, which can be used #@ for creating signatures, but which cannot be exported or whatever. #@ It also has a different password than the true and full private key. #@ ~/sec.arena/pgp-nosecrets.git/gpg.conf #@ For GPG v1. #@ No secring at all, only the public key for encryption, e.g.: #@ gpg --homedir="${HOME}/sec.arena/pgp-nosecrets.git" < IN > OUT I always write that verbose because i have no idea of all this and since it is so far off my "normal life" i tend to forget what this is all about very soon; "ewig und drei Tage" ("everlasting and three days") was a common idiom of my Grandma. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From jonkomer at yandex.com Wed Jan 26 23:03:45 2022 From: jonkomer at yandex.com (jonkomer) Date: Wed, 26 Jan 2022 15:03:45 -0700 Subject: Preventing public key upload to key-servers Message-ID: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> Is there anything that a public key owner can do, to actually *ensure* that, if some careless or malicious correspondent ignores the comment ("Please do not upload...") and attempts to upload his or her (otherwise fully functional) public key to the key-server(s), the key upload is rejected? TIA, Jon K. From tlikonen at iki.fi Thu Jan 27 07:25:09 2022 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 27 Jan 2022 08:25:09 +0200 Subject: Backup of GPG private keys? In-Reply-To: References: Message-ID: <87bkzxbsqi.fsf@iki.fi> * 2022-01-26 08:15:30+0000, Mogens Jensen via Gnupg-users wrote: > As of GnuPG (LTS) version 2.2.33, what is the recommended way to backup > your GPG private keys on a Linux system? > > 1. Backing up the entire ~./gnupg directory? Yes. Just normal backup is good and often enough. Just store the backups at least as safe as your ~/.gnupg directory. Very old backups may not be fully compatible with newer versions of GnuPG. Although GnuPG may have some automatic mechanism to convert from older file formats. > 2. Exporting only the keys? The OpenPGP export format is good too because it does not depend on the current file format. The export format should be compatible with almost any OpenPGP implementation. If you backup important long-term keys outside your normal computers I suggest using the export format: "gpg --export-secret-keys". -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 434 bytes Desc: not available URL: From felix.klee at inka.de Thu Jan 27 14:29:47 2022 From: felix.klee at inka.de (Felix E. Klee) Date: Thu, 27 Jan 2022 14:29:47 +0100 Subject: Limit access to unlocked OpenPGP SmartCard? Message-ID: <8735l9mhmc.fsf@inka.de> After I unlock an OpenPGP SmartCard V2.1 in my SPR332 [mod][1], I can use it to decrypt as many files as I want. While this is convenient, it is not great if the system is compromised and I forget to unplug the card reader. Is there any way to limit how long the OpenPGP SmartCard remains unlocked? [1]: https://github.com/feklee/0.332 From felix.klee at inka.de Thu Jan 27 22:39:52 2022 From: felix.klee at inka.de (Felix E. Klee) Date: Thu, 27 Jan 2022 22:39:52 +0100 Subject: Limit access to unlocked OpenPGP SmartCard? In-Reply-To: <20220127135447.GA9@sh4-5.1blu.de> References: <8735l9mhmc.fsf@inka.de> <20220127135447.GA9@sh4-5.1blu.de> Message-ID: On Thu, 27 Jan 2022 at 14:54, Matthias Apitz wrote: > gpgconf --reload scdaemon Gotta try that, maybe execute it with a timer, better than nothing. Best would be if the card itself could be configured to only do a certain number of operations after being unlocked. I think everything else is pretty much unsafe as well. From jcb62281 at gmail.com Fri Jan 28 03:28:55 2022 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 27 Jan 2022 20:28:55 -0600 Subject: Limit access to unlocked OpenPGP SmartCard? In-Reply-To: <8735l9mhmc.fsf@inka.de> References: <8735l9mhmc.fsf@inka.de> Message-ID: <61F354E7.4000604@gmail.com> Felix E. Klee wrote: > After I unlock an OpenPGP SmartCard V2.1 in my SPR332 [mod][1], I can > use it to decrypt as many files as I want. While this is convenient, it > is not great if the system is compromised and I forget to unplug the > card reader. > > Is there any way to limit how long the OpenPGP SmartCard remains > unlocked? > Does your smartcard reader have its own keypad for entering the PIN? If not and you are concerned about a possible system compromise, you have bigger problems, like the possibility for your smartcard PIN to be stolen as you enter it. If you then leave the card in the reader, Mallory can abuse it at his leisure. Even if you only insert the card when you intend its use, Mallory could plant malware that waits for the card to be inserted, then abuses it. -- Jacob From wk at gnupg.org Fri Jan 28 08:18:13 2022 From: wk at gnupg.org (Werner Koch) Date: Fri, 28 Jan 2022 08:18:13 +0100 Subject: Backup of GPG private keys? In-Reply-To: <87bkzxbsqi.fsf@iki.fi> (Teemu Likonen's message of "Thu, 27 Jan 2022 08:25:09 +0200") References: <87bkzxbsqi.fsf@iki.fi> Message-ID: <87pmocfhvu.fsf@wheatstone.g10code.de> On Thu, 27 Jan 2022 08:25, Teemu Likonen said: > outside your normal computers I suggest using the export format: "gpg > --export-secret-keys". Note that there is an attack on the private key export format. Thus my recommendation not to rely on this unless you can make sure that the exported keys in the backup have not been modified. The problem here is that the public parts of the encrypted private parts are not authenticated and by modifying the public parts and tricking the user to import such a modified backup, information about the secret key can be revealed. GnuPG's internal format to store the private key is not affected by this problem because the public parameters are authenticated. 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 felix.klee at inka.de Fri Jan 28 10:10:21 2022 From: felix.klee at inka.de (Felix E. Klee) Date: Fri, 28 Jan 2022 10:10:21 +0100 Subject: Limit access to unlocked OpenPGP SmartCard? References: <8735l9mhmc.fsf@inka.de> <61F354E7.4000604@gmail.com> Message-ID: <87bkzwjkea.fsf@inka.de> Jacob Bachmeyer via Gnupg-users writes: >> After I unlock an OpenPGP SmartCard V2.1 in my SPR332 [mod][1], [?] > > Does your smartcard reader have its own keypad for entering the PIN? yes From foss at morgwai.pl Fri Jan 28 06:11:01 2022 From: foss at morgwai.pl (Piotr Morgwai Kotarbinski) Date: Fri, 28 Jan 2022 12:11:01 +0700 Subject: bash script to get WKD URL for a given email Message-ID: <73ca9662-0872-dbce-2b00-70aff3a527eb@morgwai.pl> Maybe someone will find it useful: https://gist.github.com/morgwai/016fae4fd22f01e225509b76fee1d6c7 Cheers! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Fri Jan 28 15:51:49 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 28 Jan 2022 14:51:49 +0000 Subject: Preventing public key upload to key-servers In-Reply-To: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> Message-ID: On 26/01/2022 22:03, jonkomer via Gnupg-users wrote: > Is there anything that a public key owner can do, to actually > *ensure* that, if some careless or malicious correspondent > ignores the comment ("Please do not upload...") and attempts > to upload his or her (otherwise fully functional) public key > to the key-server(s), the key upload is rejected? The short answer is "no", or at best "not yet". There is a "keyserver preferences/no-modify" flag defined in rfc4880: ``` 0x80 | No-modify | The key holder requests that this key only be modified or updated by the key holder or an administrator of the key server. ``` But this is technically fraught. Most keyservers just ignore this flag, while keys.openpgp.org effectively assumes that it is always set, but even then doesn't behave exactly as the spec implies. keys.openpgp.org will not publish the userID of a key until the key's purported owner performs an email-based verification, and won't serve third-party sigs at all. It will however serve the non-userID components (by fingerprint search) no matter who uploaded it. Synchronising keyservers don't perform the verification step, due to conceptual incompatibilities between the (universal) sync model and (subjective) verification, and so the full key material will be made available regardless of who uploads them. There was a proposal in the old rfc4880bis draft that the "no-modify" flag should specifically prevent distribution of non-attested third-party sigs, but this would still not affect distribution of the userIDs and self-sigs, and has not been replicated in the new crypto-refresh draft. It is also quite likely that once sig attestations become commonplace, keyservers will stop distributing non-attested third-party sigs regardless of whether a key owner sets this flag. Note also that a domain administrator can publish the key of any email address in the domain via WKD, and this is effectively equivalent to publishing it on a keyserver. A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Fri Jan 28 19:56:17 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 28 Jan 2022 19:56:17 +0100 Subject: bash script to get WKD URL for a given email In-Reply-To: <73ca9662-0872-dbce-2b00-70aff3a527eb@morgwai.pl> References: <73ca9662-0872-dbce-2b00-70aff3a527eb@morgwai.pl> Message-ID: <51362260.8DaCNGpcMa@breq> On Freitag, 28. Januar 2022 06:11:01 CET Piotr Morgwai Kotarbinski via Gnupg-users wrote: > Maybe someone will find it useful: > https://gist.github.com/morgwai/016fae4fd22f01e225509b76fee1d6c7 At least GnuPG 2.3 includes gpg-wks-client which, among other commands, has a command to print the WKD URL for the given user id, e.g. ``` $ gpg-wks-client --print-wkd-url wk at gnupg.org https://openpgpkey.gnupg.org/.well-known/openpgpkey/gnupg.org/hu/nq6t9teux7edsnwdksswydu4o9i5es3f?l=wk ``` Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From jonkomer at yandex.com Fri Jan 28 21:02:03 2022 From: jonkomer at yandex.com (jonkomer) Date: Fri, 28 Jan 2022 13:02:03 -0700 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> Message-ID: <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> > A. G. via : > The short answer is "no", or at best "not yet"... Thank you very much for the response and comprehensive comments. In this case, the mail domain owner is actually the one that needs this level of control: he insists on the ability to positively respond to individual e-mail users' GDPR "forget me" requests. He is running an in-house mail server, and would like to direct "members" to use OpenGP encrypted mail for all member-to-member communication, and encourage the same for members' "general" e-mail correspondence. To this end it is desirable to give the users the option to create "personalized" mail account addresses (i.e., ) and include their first/last name in the public key. Domain owner intends to operate a "members only" public key dissemination and fingerprint verification mechanism. When the user is removed from the "membership", (either by the domain owner action or by his or her own request), the mail address (and any/all other personal data) is deleted and promptly removed from the publicly exposed Internet domain presence. In order to use OpenPG encrypted mail with the correspondents on other domains, the user must attach his public key to an outgoing message as the domain owner does not serve keys to the general Internet population. However, while the user/key is active, and with the user's permission, anybody in the possession of the public key can verify the fingerprint using the the same mechanism as is provided to the members. After the user removal the domain owner is ipso facto GDPR compliant. However, he would prefer that a naive user (rightly or not) does not consider him unresponsive, and both sides have some interest in preventing any Internet server from keeping an active and publicly exposed user's name and (now defunct) e-mail-address, thus indiscriminately advertising forever the fact that John Doe was at some point in time a member of Example.org. How do individual key-server owner/operators react to formal GDPR "forget me" requests; either by e-mail users, or by mail domain owners? Any known legal precedents? Jon K. From felix.klee at inka.de Fri Jan 28 23:32:55 2022 From: felix.klee at inka.de (Felix E. Klee) Date: Fri, 28 Jan 2022 23:32:55 +0100 Subject: Limit access to unlocked OpenPGP SmartCard? References: <8735l9mhmc.fsf@inka.de> Message-ID: <877dajo5ig.fsf@inka.de> Well, I think I could extend my SPR332 [mod][1]: * Add a push-button that one has to press to close the C7 circuit for I/O. Without that button pressed, the smart card cannot communicate with the reader. That means, for every operation, one would need to hold that button, kind of ? but not as elegantly ? as with a YubiKey. * Using some electronics detect when the green PIN pad ?-button is pressed to confirm PIN entry on the reader. Let it trigger a timer that cuts I/O for good after a few minutes. Very likely there are some issues that I don?t see at the moment. [1]: https://github.com/feklee/0.332 From johanw at vulcan.xs4all.nl Sat Jan 29 02:55:51 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 29 Jan 2022 02:55:51 +0100 Subject: Preventing public key upload to key-servers In-Reply-To: <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: On 28-01-2022 21:02, jonkomer via Gnupg-users wrote: > How do individual key-server owner/operators react to > formal GDPR "forget me" requests; either by e-mail users, or > by mail domain owners? Any known legal precedents? There are known technical issues: the HKP keyserver does not allow keys to be removed, GDPR or not. When the keyserer operator operates outside of the EU I don't think that is a legal problem. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From jonkomer at yandex.com Sat Jan 29 04:43:08 2022 From: jonkomer at yandex.com (jonkomer) Date: Fri, 28 Jan 2022 20:43:08 -0700 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: > When the keyserer operator operates outside > of the EU I don't think that is a legal problem. If an individual that requests his personal information is removed (i.e., the "right to be forgotten") is EU resident, GDPR applies regardless of the jurisdiction in which the information server is located. Jon K. From jcb62281 at gmail.com Sat Jan 29 05:26:31 2022 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 28 Jan 2022 22:26:31 -0600 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: <61F4C1F7.6000106@gmail.com> jonkomer via Gnupg-users wrote: >> When the keyserer operator operates outside >> of the EU I don't think that is a legal problem. > > If an individual that requests his personal information is > removed (i.e., the "right to be forgotten") is EU resident, > GDPR applies regardless of the jurisdiction in which the > information server is located. It may *purport* to apply, but if the keyserver is outside of EU jurisdiction, the server is outside of EU jurisdiction. This is a very good thing, or would you prefer to be subject to whatever "long arm" nonsense Communist China can cook up? -- Jacob From skquinn at rushpost.com Sat Jan 29 04:51:02 2022 From: skquinn at rushpost.com (Shawn K. Quinn) Date: Fri, 28 Jan 2022 21:51:02 -0600 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: <62179ef0-0a20-c045-89a4-384483620852@rushpost.com> On 1/28/22 21:43, jonkomer via Gnupg-users wrote: > If an individual that requests his personal information is > removed (i.e., the "right to be forgotten") is EU resident, > GDPR applies regardless of the jurisdiction in which the > information server is located. > > Jon K. If the server is physically in the US, administered by someone residing in the US, is the EU really expecting US courts to enforce EU laws/directives like the GDPR on a US citizen? That's the big issue with a "right to be forgotten" law: every country or almost every country has to be in agreement to enforce it or it's pretty much worthless. -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com From rjh at sixdemonbag.org Sat Jan 29 07:42:36 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 29 Jan 2022 01:42:36 -0500 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> > If an individual that requests his personal information is > removed (i.e., the "right to be forgotten") is EU resident, > GDPR applies regardless of the jurisdiction in which the > information server is located. "Right to be forgotten" doesn't exist in the United States. It's a violation of our First Amendment, which guarantees our right to communicate essentially anything that's true -- and even many things that are false! -- so long as we haven't signed a security clearance agreement. We take this so seriously that when a major news magazine wanted to publish accurate details about the design of nuclear weapons, they were allowed to do so and no one went to jail for it. (_The Progressive,_ November 1979, if you feel like looking it up in your library. It was the first public release of the physics behind the H-bomb.) If the United States is forbidden from stopping me from sharing facts about nuclear weapon design, it's also going to be forbidden from enforcing the GDPR's prohibition on my telling other people your email address. The EU likes to claim the GDPR applies everywhere information on EU residents is kept. So long as we've got United States Marines, y'all are going to have real problems convincing us of that. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Sat Jan 29 09:33:42 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 29 Jan 2022 09:33:42 +0100 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: <3c60c56e-7c3f-d78a-3a6a-437401cd0390@vulcan.xs4all.nl> On 29-01-2022 4:43, jonkomer via Gnupg-users wrote: >> When the keyserer operator operates outside >> of the EU I don't think that is a legal problem. > If an individual that requests his personal information is > removed (i.e., the "right to be forgotten") is EU resident, > GDPR applies regardless of the jurisdiction in which the > information server is located. That's what the EU claims. Other countries can value that opinion just as much as some other countries that want people convicted outside their borders for insulting Dear Leader. If the EU isn't ready to use the ultimate law (might makes right) then it's just a dead letter. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From jonkomer at yandex.com Sat Jan 29 17:38:24 2022 From: jonkomer at yandex.com (jonkomer) Date: Sat, 29 Jan 2022 09:38:24 -0700 Subject: First Amendment and Marines? In-Reply-To: <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> Message-ID: My personal preferences have nothing to do with the topic discussed here. I was simply trying to help an organization that is, for *their own good business reasons* very much motivated to adhere to GDPR, use existing IT infrastructure to move to a more secure method of communication. I was the one to suggest to them to use e-mail and OpenPG encryption. The reasons were two-fold: first to avoid one of those centralized, web-browser based, single-point-of-failure, essentially insecure communication setups so common today; the second was to make their member's communication interoperable with general Internet population in order to increase organization's visibility and promote wider adoption of encrypted e-mail. I posted my original question only in order to find out some technical details on how to do that. Posting the question was worthwhile, as I have learned that: (a) Unfortunately, OpenPG email encryption is incompatible with GDPR and should not be used by those that either want or need to be GDPR compliant. (b) GDPR appears to be a topic that, for some strange reason, elicits emotional reactions by the OpenPG creators and maintainers. (c) GPG and OpenPG appear to be very much US-centric endevours. That fact ought to be taken into account by the new users. If the ultimate goal of OpenPG is the wider adaption of encrypted e-mail, finding technical means to make it usable by those that *wish to be GDPR compliant* - without forcing such MO on everyone - appears to be a worthwhile effort. I thank again to all that have contributed their answers, comments and opinions. Jon K. From lists at binarus.de Sat Jan 29 17:34:54 2022 From: lists at binarus.de (Binarus) Date: Sat, 29 Jan 2022 17:34:54 +0100 Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page) In-Reply-To: <202112031204.31216.bernhard@intevation.de> References: <202112020957.12700.bernhard@intevation.de> <202112031204.31216.bernhard@intevation.de> Message-ID: On 03.12.2021 12:04, Bernhard Reiter wrote: > First I wanted to gather some feedback, especially about the following > section, where I've added a recommendation what to use instead > of incompatible header encryption: > > > | Transport information in a decentral network - just like the writing on the > | outside of a postal mail envelope - cannot be protected in principle. > | When reflecting on this, chose a subject that is plausible in context, > | but without sensitive contents, to best veil potential unwanted observers. > | (Your thinking is right: The more sensitive this is, the more you have > | to build up a plausible context for your unavoidable traces first.) I didn't read the wiki page yet, but I'd like to comment on that paragraph. I agree in part, but not completely. The idea is nice, but can't be realized in practice. From my personal experience, it is very hard and consumes time to find appropriate subject lines. After all, when using OpenPGP in business, recipients invest 5 seconds per message at maximum when scanning the list of received messages to decide what message to read first. "Wrong" subject lines are not helpful in this context. That means that your suggestion may be valid for private communication, but not for business. Rather, it is often good style and really simplifies things if some important (sensitive) data is in the subject line. As an example, imagine that you are communicating with your health insurance company. The staff there usually is very grateful if they see your insurance number in the subject line, plus a few keywords (in German, for example, "K?ndigung", "Leistungsantrag" etc.). Not following this convention costs them time and effort and is bad style. Apart from that, you'll have some trouble yourself with that strategy. Imagine you have to find a message you have sent two years ago. That could be hard if you have "faked" the subject lines. Furthermore, the recipient will hopefully answer your message one day, and will typically do this by just hitting the "Reply" button. That means the answer comes back with the same "fake" subject line you originally had chosen, and that game will continue until the communication on this subject has ceased. In the end, you have 50 sent messages and 50 received messages with a "wrong" subject line. Your comparison with snail mail is the right way to understand the issue: Did you ever receive a letter from your health insurance which carried the actual subject on the *outside* of the *envelope* (example subject of a letter from your health insurance: "Payment for your HIV treatment")? I didn't, and I'll have a very serious talk with the sender if I ever do. *Every* piece of data should be protected, especially in electronic communication, except the transportation data which technically is absolutely necessary to get the transport done. In the same way the postal service does not need to know the content of a letter (including the subject) to transport it from the sender to the recipient, SMTP servers do not need to know the subject to transport messages. SMTP basically needs only the sender address (strictly looking at it, not even that, but it is important for bounces and replies) and the recipient address. Sad to say that SMTP servers usually dynamically add headers during transport which already can put somebody at risk, but I guess we'll have to live with that for the moment. A subject line really does not fall into the category of transportation data. SMTP servers don't need to know it to transport the message, and it can (and in most cases, will) contain sensitive data. We shouldn't call something transportation data solely because it is in a header. I am very grateful that we can finally encrypt the subject line with most OpenPGP implementations since several years. Actually, not being able to do this kept me from using PGP (in E-Mail) for a while. Now I always encrypt the subject line, and so do my communication partners. If there are MUAs out there which can't cope with that, refraining from encrypting the subject would be the wrong reaction. Instead, people using such a MUA should be educated to use another MUA. PGP implementations have undergone changes which were much more "breaking" than encrypted subject lines. Best regards, Binarus From rjh at sixdemonbag.org Sat Jan 29 18:58:41 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 29 Jan 2022 12:58:41 -0500 Subject: First Amendment and Marines? In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> Message-ID: <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> > I was simply trying to help an organization > that is, for *their own good business reasons* very much > motivated to adhere to GDPR, use existing IT infrastructure > to move to a more secure method of communication. And, for those people and businesses who have to do business with the EU, the GDPR is worth complying with even when it's not strictly enforceable. For instance, United States airline companies that fly into the EU voluntarily comply with the GDPR for EU citizens flying within the United States, because if they don't they might find their access to European airports restricted. But if you're an American without EU ties, the GDPR is yet another piece of foreign legislation we don't need to pay attention to. And when Europeans baldly say "the GDPR applies worldwide, you must follow it," what we hear is "the EU overrides your silly Constitution." At which point we tell you to have that argument with the Marines, please. That position you're pushing is a thoroughly silly one, and it deserves to be called out as such. I don't hate you. I don't dislike you. I don't hold you in contempt. In fact, I don't even *know* you. You said something many Americans find very silly, and we laughed. That's all that happened. :) > (a) Unfortunately, OpenPG email encryption is incompatible > with GDPR and should not be used by those that either want > or need to be GDPR compliant. No, it's quite possible to be GDPR compliant, as evidenced by the fact the German government has adopted it. I'm pretty sure the German government has a number of lawyers specializing in EU regulation, and they're fine with it. Perhaps you might want to ask, "how is the German government complying with GDPR?" > (c) GPG and OpenPG appear to be very much US-centric > endevours. It's not. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jotoho+mailinglist at jotoho.de Sat Jan 29 18:30:38 2022 From: jotoho+mailinglist at jotoho.de (Jonas Tobias Hopusch) Date: Sat, 29 Jan 2022 18:30:38 +0100 Subject: First Amendment and Marines? In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> Message-ID: <20220129173038.unb7gifl2o5gsgdq@jotoho.de> Small correction: The standard is called OpenPGP, not OpenPG. IIRC, OpenPGP is an open protocol specification by the IETF that succeeded the original proprietary Pretty Good Privacy. GNU Privacy Guard (often abbreviated to GnuPG or GPG), the software this mailing- list is for, is merely one implementation of the standard (albeit an extremely widespread one). Sorry if I come across condescending, my intention is only to avoid misunderstandings. -- Jonas Tobias Hopusch OpenPGP Keys for encrypted communication are available via Web Key Directory (WKD) or from https://downloads.jotoho.de/openpgp/ From felix.klee at inka.de Sat Jan 29 22:24:03 2022 From: felix.klee at inka.de (Felix E. Klee) Date: Sat, 29 Jan 2022 22:24:03 +0100 Subject: YubiKey 5C NFC not detected Message-ID: <87r18q5j7w.fsf@inka.de> I would like to set up a YubiKey 5C NFC for SSH, but it doesn?t get detected by GnuPG: $ ykman config usb -l OTP FIDO U2F FIDO2 OATH PIV OpenPGP YubiHSM Auth $ cat .gnupg/scdaemon.conf reader-port Yubico Yubi $ gpgconf --kill gpg-agent $ ps x | grep scdaemon 33408 ? SLl 0:00 scdaemon --multi-server 49465 pts/2 S+ 0:00 grep scdaemon $ /usr/lib/gnupg/scdaemon --version scdaemon (GnuPG) 2.2.32 libgcrypt 1.9.4-unknown libksba 1.6.0 Copyright (C) 2021 Free Software Foundation, Inc. License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ gpg --verbose --card-status gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device What can I do? From kloecker at kde.org Sat Jan 29 23:19:47 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 29 Jan 2022 23:19:47 +0100 Subject: First Amendment and Marines? In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> Message-ID: <2399161.Ij1gHSXJXQ@breq> On Samstag, 29. Januar 2022 17:38:24 CET jonkomer via Gnupg-users wrote: > Posting the question was worthwhile, as I have learned > that: > > (a) Unfortunately, OpenPG email encryption is incompatible > with GDPR and should not be used by those that either want > or need to be GDPR compliant. I disagree with this conclusion. For example, you could use OpenPGP keys with pseudonymous user ids or even with identical user ids. Obviously, this would make using OpenPGP more difficult because the email clients couldn't easily map OpenPGP keys to email addresses. OTOH, some email clients actually support mapping of OpenPGP keys to contacts. Maybe even the company's internal address book could be used for this. This way uploading those OpenPGP keys to keyservers wouldn't leak email addresses. Arguably, the OpenPGP keys themselves could still be considered as person identifiable information. In this case, you might want to use symmetric encryption (which OpenPGP also supports). But that makes using encryption even more difficult because now you have to share the passwords used for symmetric encryption and, at the same time, make sure that those passwords are kept secret. > (b) GDPR appears to be a topic that, for some strange reason, > elicits emotional reactions by the OpenPG creators and > maintainers. I don't know who you mean by "the OpenPGP creators and maintainers". Neither Phil Zimmermann, the original author of PGP, nor Werner Koch, the original author and maintainer of GnuPG, have participated in this thread. OTOH, some people who have replied to you are also on the mailing list where the future of the OpenPGP standard is discussed. > (c) GPG and OpenPG appear to be very much US-centric > endevours. That fact ought to be taken into account by the > new users. I find it ironic that you are accusing GnuPG of being a US-centric endeavor. You really need to do some more research before jumping to such absurd conclusions. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Sat Jan 29 23:24:38 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 29 Jan 2022 23:24:38 +0100 Subject: YubiKey 5C NFC not detected In-Reply-To: <87r18q5j7w.fsf@inka.de> References: <87r18q5j7w.fsf@inka.de> Message-ID: <2778274.reUcr414bH@breq> On Samstag, 29. Januar 2022 22:24:03 CET Felix E. Klee wrote: > I would like to set up a YubiKey 5C NFC for SSH, but it doesn?t get > detected by GnuPG: > > $ ykman config usb -l > OTP > FIDO U2F > FIDO2 > OATH > PIV > OpenPGP > YubiHSM Auth > $ cat .gnupg/scdaemon.conf > reader-port Yubico Yubi Are you sure "Yubico Yubi" is the correct value for the reader-port option? Did you try without specifying this option? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From raubvogel at gmail.com Sat Jan 29 22:29:31 2022 From: raubvogel at gmail.com (Mauricio Tavares) Date: Sat, 29 Jan 2022 16:29:31 -0500 Subject: First Amendment and Marines? In-Reply-To: <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> Message-ID: On Sat, Jan 29, 2022 at 12:59 PM Robert J. Hansen via Gnupg-users wrote: > > > I was simply trying to help an organization > > that is, for *their own good business reasons* very much > > motivated to adhere to GDPR, use existing IT infrastructure > > to move to a more secure method of communication. > > And, for those people and businesses who have to do business with the > EU, the GDPR is worth complying with even when it's not strictly > enforceable. For instance, United States airline companies that fly > into the EU voluntarily comply with the GDPR for EU citizens flying > within the United States, because if they don't they might find their > access to European airports restricted. > > But if you're an American without EU ties, the GDPR is yet another piece > of foreign legislation we don't need to pay attention to. And when Not quite. It cares about personal data from people residing in Europe at the time said data was collected. And even then, you need to be targeting EU/EEA residents. So, if a German citizen goes to FL and needs to stop at the emergency care to have a shark bite taken care of, that data now is owned by the hospital forever, which will figure out how to make money with it without asking permission. > Europeans baldly say "the GDPR applies worldwide, you must follow it," > what we hear is "the EU overrides your silly Constitution." One can argue that the US has done the same. Some of it -- if you want to do business in the US, you better follow American rules -- makes sense though, but we are difressing here. > At which point we tell you to have that argument with the Marines, > please. That position you're pushing is a thoroughly silly one, and it > deserves to be called out as such. > > I don't hate you. I don't dislike you. I don't hold you in contempt. > In fact, I don't even *know* you. You said something many Americans > find very silly, and we laughed. That's all that happened. :) > > > (a) Unfortunately, OpenPG email encryption is incompatible > > with GDPR and should not be used by those that either want > > or need to be GDPR compliant. > > No, it's quite possible to be GDPR compliant, as evidenced by the fact > the German government has adopted it. I'm pretty sure the German > government has a number of lawyers specializing in EU regulation, and > they're fine with it. > I not only agree but also would add that The Bundesamt f?r Sicherheit in der Informationstechnik (German Federal Office for Information Security) itself, which handles computer and communication security -- critical infrastructure protection, internet security, certification of security products -- for the German government, uses it. Badly at times[1], but that is another bag of cats. > Perhaps you might want to ask, "how is the German government complying > with GDPR?" > Better than the Irish government, but once again I digress. > > (c) GPG and OpenPG appear to be very much US-centric > > endevours. > > It's not. I agree. Given that it is open source, you can run your own setup completely independently, including web of trust. Therefore, you can control data lifetime. [1] https://www.somethingofdoom.com/2021/11/german-federal-office-for-information.html From angel at pgp.16bits.net Sun Jan 30 01:13:34 2022 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 30 Jan 2022 01:13:34 +0100 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: On 2022-01-28 at 20:43 -0700, jonkomer wrote: > > When the keyserer operator operates outside > > of the EU I don't think that is a legal problem. > > If an individual that requests his personal information is > removed (i.e., the "right to be forgotten") is EU resident, > GDPR applies regardless of the jurisdiction in which the > information server is located. > > Jon K. Not really. If an EU resident is travelling on nonEUland, the GDPR wouldn't apply. And it protect as well an noneulander which was only temporarily on EU. In order for the GDPR to apply to a company (controller/processor) not established in the EU, the people whose data is being processed must be in the EU (irrespective of whether they are a resident or staying for a couple of days) and the company would need to be: a) offering of goods or services (even if it's for free) to such people in the Union; or b) monitoring their behavior (which takes place in the Union) See article 3 for the details: https://gdpr.eu/article-3-requirements-of-handling-personal-data-of-subjects-in-the-union/ Best regards From angel at pgp.16bits.net Sun Jan 30 02:08:08 2022 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 30 Jan 2022 02:08:08 +0100 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> Message-ID: (changing back the thread subject) On 2022-01-29 at 09:38 -0700, jonkomer wrote: > I was the one to suggest to them to use e-mail and OpenPG > encryption. The reasons were two-fold: first to avoid one of > those centralized, web-browser based, single-point-of-failure, > essentially insecure communication setups so common today; > the second was to make their member's communication > interoperable with general Internet population in order > to increase organization's visibility and promote wider > adoption of encrypted e-mail. I posted my original question > only in order to find out some technical details on how to > do that. > > Posting the question was worthwhile, as I have learned > that: > > (a) Unfortunately, OpenPG email encryption is incompatible > with GDPR and should not be used by those that either want > or need to be GDPR compliant. That's a non-sequitur from the thread. Your GDPR issue is with people uploading keys to the PGP keyservers without consent, not with OpenPGP (which doesn't need keyserver nor even specify the use of keyservers, although they are related technology). Think about it: If you sent me a physical letter full of personal information, and I then publish it on the newspaper, with no legitimacy to do so, in violation of GDPR. Would that make snail-mail incompatible with GDPR? Regarding your problem, I would suggest not to include the first/last name in the key. Only the email address. (Yes, the name part is optional). So instead of John Smith if would simply be The name part is inherently unreliable, since it cannot know if the owner is *the* John Smith you want to write to (assuming the user is actually named John Smith!). On the other hand, the key can be easily matched with the provided email address. Of course, a member wanting to correspond with John Smith needs to find out that their email is john.doe at example.org but that was likely already the case before, and something which is probably solved through that "internal verification mechanism" (which I'm a bit wary about, I would recommend that the keys were provided signed by the domain owner, so members would only need to trust(sign) that key to know that they have a valid example.org pgp key. They could be published through WKD. This doesn't preclude that access to the keys could require authentication). A second issue on having the users rely (and the owner needing to assert) on the name displayed on the key would have been what to do when a second John Smith wanted to become a member. Best regards PS: I guess by the "emotional reactions" you mean Robert J. Hansen mails, since replies by other people seem much more technical in nature. You shouldn't generalize from one person to "all creators and maintainers". In fact, I think -but have not checked- that most of GnuPG code will have been written inside the EU. There are lots of OpenPGP users inside the EU, under GDPR, including Government entities (as Robert J Hansen noted). From rjh at sixdemonbag.org Sun Jan 30 02:19:47 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 29 Jan 2022 20:19:47 -0500 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> Message-ID: > PS: I guess by the "emotional reactions" you mean Robert J. Hansen > mails, since replies by other people seem much more technical in > nature. If by 'emotional' people mean 'amused', then yes. I thought it was cuter than a pailful of kittens. :) If by 'emotional' people mean angry, annoyed, or perturbed, then no. > You shouldn't generalize from one person to "all creators and > maintainers". Especially given that I'm neither of the two! -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From angel at pgp.16bits.net Sun Jan 30 04:04:22 2022 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 30 Jan 2022 04:04:22 +0100 Subject: pgp263iamulti06 In-Reply-To: <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> Message-ID: <0f5a59a0fb93b6c83c4f3a3245fd3a3cdba1a0c8.camel@16bits.net> On 2022-01-23 at 15:23 -0500, Robert J. Hansen wrote: > > When generating the key-pair with Re: pgp263iamulti06, the > > "randomness" is obtained by user's keyboard input. Is it > > then that the above applies only when the session key is > > generated? > > No, the whole CSPRNG is (probably) compromised. PGP 2.6.3 used keyboard > interrupts harvested directly from the hardware to get a collection of > random bits which it then fed into the CSPRNG to be expanded out into a > large quantity of randomish bits. It's just that when generating a new > certificate it always replenished the CSPRNG's entropy -- when > generating traffic it didn't, but the CSPRNG was still dependent on the > randomness collected earlier. > > On Windows, you no longer have this direct access to hardware and > there's almost certainly some determinism introduced by the HAL. Ok, you made me actually look at pgp263iamulti06. :-) It seems to be using ANSI X9.17 but built on CAST5. ANSI X9.17 has been removed by NIST, and CAST5 has a block size of only 64 bits. Nevertheless, it probably is a decent enough CSPRNG nowadays. Way out of my reach, anyway. However, the entropy gathering seems overly optimistic: It doesn't seem to take timing into account,* just the keystrokes themselves.** It discards more than two consecutive presses of the same key, but other than that, it will be assuming about 7 bits of entropy per key-press. Whereas the user will be typing with a keyboard which doesn't even have 2^7 keys. Perhaps up to 5 bits of randomness, more likely on the order of 2^4 different keys, and the keys pounded by the user won't be independent events, so not even 4 bits of entropy. There are lots of further mixing (including additional randomness saved on randseed.bin file), but if you actually had less random bits than you thought... Regards * Time is used to ensure not fetch more than one keypress per second. ** Note: on Macintosh the implementation seem to work slightly different than the others. From vedaal at nym.hush.com Sun Jan 30 04:16:42 2022 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Sat, 29 Jan 2022 22:16:42 -0500 Subject: First Amendment and Marines? In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> Message-ID: <20220130031642.B9BD08040C3@smtp.hushmail.com> On 1/29/2022 at 5:39 PM, "Mauricio Tavares via Gnupg-users" wrote Not quite. It cares about personal data from people residing in Europe at the time said data was collected. And even then, you need to be targeting EU/EEA residents. So, if a German citizen goes to FL and needs to stop at the emergency care to have a shark bite taken care of, that data now is owned by the hospital forever, which will figure out how to make money with it without asking permission. ===== This is NOT true, (but may make sense to someone who has never been a hospital patient in the US.) Every hospitalized patient is given a consent form prior to treatment, which they may edit or refuse to sign. -It allows release of medical information to the Insurance Carrier, -to the Patient's private Physician, -to a third party designated by the patient as a 'next-of-kin-with medical proxy', should the patient not be in a condition to make decisions, -or to a third party statistical group following the frequency and outcome of a particular condition requiring hospitalization. The patient can choose any, all, any combination, or none of them. And still get treatment. Vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at pgp.16bits.net Sun Jan 30 04:25:24 2022 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 30 Jan 2022 04:25:24 +0100 Subject: Backup of GPG private keys? In-Reply-To: <87pmocfhvu.fsf@wheatstone.g10code.de> References: <87bkzxbsqi.fsf@iki.fi> <87pmocfhvu.fsf@wheatstone.g10code.de> Message-ID: <1311b41f5d2dc2414aa68d2df0cae4232cf6af68.camel@16bits.net> On 2022-01-28 at 08:18 +0100, Werner Koch wrote: > The problem here is that the public parts of the encrypted private > parts are not authenticated and by modifying the public parts and > tricking the user to import such a modified backup, information about > the secret key can be revealed. I'm a bit confused by this claim, Werner. Say you fetch your key backup from Mallory's safe, and take it to your basement. The import wouldn't be an online process with timing leaks. The feedback that Mallory might get is his friend at the door blaming him for providing a tampered backup. The private part wouldn't be modifiable without the passphrase. And if the public part was changed, it would no longer match the secret part (or it could match the secret key, but have a different creation timestamp and be effectively a different key than the one you were expecting to restore), so it should get rejected. And pubkey with a prime of 1 shall be invalid. Some preferences could be added/stripped from the public key (undesirable), but that's far from revealing information from the secret key. Could you elaborate? I am surely missing something. Best regards From plr.vincent at gmail.com Sun Jan 30 03:36:59 2022 From: plr.vincent at gmail.com (Vincent Pelletier) Date: Sun, 30 Jan 2022 02:36:59 +0000 Subject: Preventing public key upload to key-servers In-Reply-To: <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: <20220130023659.5e6857ac@gmail.com> On Fri, 28 Jan 2022 13:02:03 -0700, jonkomer via Gnupg-users wrote: > After the user removal the domain owner is ipso facto > GDPR compliant. However, he would prefer that a naive user > (rightly or not) does not consider him unresponsive, and both > sides have some interest in preventing any Internet server > from keeping an active and publicly exposed user's name > and (now defunct) e-mail-address, thus indiscriminately > advertising forever the fact that John Doe was at some point > in time a member of Example.org. How many signatures are expected to be on such key ? If there are none (or maybe very few, especially if none links to example.org administration), then would it be reasonable to argue that this key can have been forged and the association with that domain is an unverifiable claim ? I have no idea how it would legally fly, and there is certainly a question of scale (enough individually unverifiable but globally concordant claims become a globally convincing picture). Unrelated note: I find the rhetoric of a few posts in this thread absolutely astounding. From a crypto question to red scare and "my army is going to kick your country's ass if it dares talk to me" in two easy steps ? This is vile. -- Vincent Pelletier GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1 From rjh at sixdemonbag.org Sun Jan 30 04:35:44 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 29 Jan 2022 22:35:44 -0500 Subject: pgp263iamulti06 In-Reply-To: <0f5a59a0fb93b6c83c4f3a3245fd3a3cdba1a0c8.camel@16bits.net> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> <0f5a59a0fb93b6c83c4f3a3245fd3a3cdba1a0c8.camel@16bits.net> Message-ID: <6b243247-19a1-6bbe-941e-e3a9230f4e39@sixdemonbag.org> > Ok, you made me actually look at pgp263iamulti06. :-) I almost feel like I should apologize. > However, the entropy gathering seems overly optimistic: *wince* That's quite a bit worse than I remember. (I haven't looked at 2.6.3 source code in probably 25 years.) So, yeah. I'm comfortable calling the 2.6.3 CSPRNG system fatally compromised due to inadequate entropy gathering. Thank you for looking into this! -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Jan 30 04:59:18 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 29 Jan 2022 22:59:18 -0500 Subject: Preventing public key upload to key-servers In-Reply-To: <20220130023659.5e6857ac@gmail.com> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <20220130023659.5e6857ac@gmail.com> Message-ID: <0865c83f-2396-1dde-fdab-6d0102533fca@sixdemonbag.org> > Unrelated note: I find the rhetoric of a few posts in this thread > absolutely astounding. From a crypto question to red scare and "my army > is going to kick your country's ass if it dares talk to me" in two easy > steps ? This is vile. "Tell it to the Marines" is a standard American and British proverb. It even has its own Wikipedia page. Television shows like "Happy Days" and "M*A*S*H" had episodes named "Tell It to the Marines", and it was even used in a "Doctor Who" episode once. The British use it to mean "I am not so foolish as to believe your claims." In America, it can have the same meaning as the British, but we also have a sense of "your plan requires that I comply, and I will not; and any attempt to compel my compliance will be resisted with overwhelming force." When someone claims that American citizens without any connection to the EU must obey EU laws, "tell it to the Marines" and its rhetorical brethren seem entirely appropriate, in both the British and American senses. It's a profoundly silly statement which, if taken seriously, would be absolutely guaranteed to be resisted vigorously by the United States. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Sun Jan 30 05:04:21 2022 From: raubvogel at gmail.com (Mauricio Tavares) Date: Sat, 29 Jan 2022 23:04:21 -0500 Subject: First Amendment and Marines? In-Reply-To: <20220130031642.B9BD08040C3@smtp.hushmail.com> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> <20220130031642.B9BD08040C3@smtp.hushmail.com> Message-ID: On Sat, Jan 29, 2022 at 10:17 PM vedaal via Gnupg-users wrote: > > On 1/29/2022 at 5:39 PM, "Mauricio Tavares via Gnupg-users" wrote > > > Not quite. It cares about personal data from people residing in > Europe at the time said data was collected. And even then, you need to > be targeting EU/EEA residents. So, if a German citizen goes to FL and > needs to stop at the emergency care to have a shark bite taken care > of, that data now is owned by the hospital forever, which will figure > out how to make money with it without asking permission. > > ===== > > This is NOT true, > (but may make sense to someone who has never been a hospital patient in the US.) > > Every hospitalized patient is given a consent form prior to treatment, which they may edit or refuse to sign. > -It allows release of medical information to the Insurance Carrier, > -to the Patient's private Physician, > -to a third party designated by the patient as a 'next-of-kin-with medical proxy', should the patient not be in a condition to make decisions, > -or to a third party statistical group following the frequency and outcome of a particular condition requiring hospitalization. > 1. I myself have been told in more than one occasion by floor supervisors I would not get service at a certain state-owned medical institution unless I signed the consent form. I believe that is also the case with covid vaccines. 2. I sat in a presentation by a certain university owned hospital about how to get access to their patients' data for research. They did state once the data is in their system, it is theirs. Yes, since they are a *medical* organization (this is a subtle detail most people are not aware of) they are subject to HIPAA, but the data is now theirs. And that while a patient could oppose to have his data used, he would have to fill out the forms for each and every single research data, which meant he had to be aware that the data was going to be used in the research. That was one of the questions *I* asked. I also asked about GDPR, to which they replied "oh, we have no European data." I did get an earful from my boss because of those questions, but hey. 3. Note the data offered was not necessarily deidentified. Let me rephrase it: deidentification of data per HIPAA, FERPA, the Privacy Act of 1974 (and its revisions), and NIST sp 800 series is at best pseudoanonymized data per GDPR. So, to quote https://www.theverge.com/2021/6/23/22547397/medical-records-health-data-hospitals-research, it is a "privacy placebo." (I really like that term) 4. https://www.nejm.org/doi/full/10.1056/NEJMp2102616 talks about "deidentified" EHR data being aggregate and sold. > The patient can choose any, all, any combination, or none of them. > And still get treatment. > Can you provide which regulation states that? I could have used it many times. > > Vedaal > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users From vedaal at nym.hush.com Sun Jan 30 05:29:03 2022 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Sat, 29 Jan 2022 23:29:03 -0500 Subject: pgp263iamulti06 In-Reply-To: References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> <0f5a59a0fb93b6c83c4f3a3245fd3a3cdba1a0c8.camel@16bits.net> <6b243247-19a1-6bbe-941e-e3a9230f4e39@sixdemonbag.org> <20220130035216.53814806146@smtp.hushmail.com> Message-ID: <20220130042903.EA247806146@smtp.hushmail.com> On 1/29/2022 at 11:02 PM, "Robert J. Hansen" wrote:> Please comment if this is adequate, or there is still a problem with > Disastry's Linux Version. Why? I've been trying to get people to move to OpenPGP for literally a quarter-century, Vedaal. I'm not going to suddenly switch gears and work on giving people reasons *not* to migrate. ===== I have publicly posted here that GnupG should not have to make a considerations with backward compatibility with Disastry's version, those who use Disastry's version among each other will continue to do so, and among those who communicate with GnuPG user's, will use GnuPG. If person1 has a signed and encrypted email to person 2, but which used IDEA and MD 5, and now wants to decrypt, and re-encrypt and sign, and send to person 2, who will then destroy the original email, why shouldn't they be allowed to know if this is safe. They still use GnuPG for current email and will not be discouraged by knowing that there is a safe way to do this in Linux based Diastry's version, which cannot be sent to person 2's v3 key in GnuPG 2.x vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Jan 30 05:37:35 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 29 Jan 2022 23:37:35 -0500 Subject: pgp263iamulti06 In-Reply-To: <20220130042903.EA247806146@smtp.hushmail.com> References: <57d99c49-0337-9141-55f5-807f736d09d6@sixdemonbag.org> <877daxgigz.fsf@wheatstone.g10code.de> <1fcfafaa-3a58-c716-6455-76f302aafb31@sixdemonbag.org> <20220118195934.010EC8235E3@smtp.hushmail.com> <904aea70-d22a-431a-7d4c-8313b985589d@safe-mail.net> <5dcf47e8-cc92-065b-ec97-0e1fadb24a8c@sixdemonbag.org> <0f5a59a0fb93b6c83c4f3a3245fd3a3cdba1a0c8.camel@16bits.net> <6b243247-19a1-6bbe-941e-e3a9230f4e39@sixdemonbag.org> <20220130035216.53814806146@smtp.hushmail.com> <20220130042903.EA247806146@smtp.hushmail.com> Message-ID: <407d4176-3a27-dd45-c151-e7226347aa70@sixdemonbag.org> > If person1 has a signed and encrypted email to person 2, but which > used IDEA and MD 5, and now wants to decrypt, and re-encrypt and > sign, and send to person 2, who will then destroy the original > email, why shouldn't they be allowed to know if this is safe. They *are* allowed. The source code is there for them to study. What I said is that I'm not going to do that work for them, because I think PGP 2.6.3 is best abandoned. Full stop. No exceptions. Migrate your data already, you've had over a quarter century. People are of course free to disagree with me: some do. But that is my position, and I think it's kind of incredible that someone would ask me to come up with reasons that would allow PGP 2.6.3 users to justify their continued use. :) From vedaal at nym.hush.com Sun Jan 30 05:39:29 2022 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Sat, 29 Jan 2022 23:39:29 -0500 Subject: First Amendment and Marines? In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> <20220130031642.B9BD08040C3@smtp.hushmail.com> Message-ID: <20220130043930.05D17806146@smtp.hushmail.com> On 1/29/2022 at 11:06 PM, "Mauricio Tavares via Gnupg-users" wrote: > The patient can choose any, all, any combination, or none of them. > And still get treatment. > Can you provide which regulation states that? I could have used it many times. ===== It's in the HIPPA act which requires the patient's consent to share the date, and is in the pre-treatment or pre-hospittalization consent form itself. The worst the hospital can do, if the person refuses release to the Insurance Company, is to bill the patient as self-pay. The hospital cannot refuse treatment. Can't speak about Covid, because *The Science* seems to vary between conservative and liberal states. There are many horror stories, but it is not for this mailing list. Vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus+gnupg at ethgen.ch Sun Jan 30 11:12:11 2022 From: klaus+gnupg at ethgen.ch (Klaus Ethgen) Date: Sun, 30 Jan 2022 11:12:11 +0100 Subject: First Amendment and Marines? In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> Message-ID: Hi, Am Sa den 29. Jan 2022 um 17:38 schrieb jonkomer via Gnupg-users: > (a) Unfortunately, OpenPG email encryption is incompatible > with GDPR and should not be used by those that either want > or need to be GDPR compliant. That is, simply to say, nonsense. There is nothing related that GDPR law that is OpenPGP related. (Independent, that the GDPR is stupidly made.) When it comes to keyservers, with the same argument you could state that bitcoin is illegal. (No information in the key chain can be removed. And there is even child porn inside that key chain that could never ever again be removed!) There are more technologies out there where informations, once in, could never removed again. Regards Klaus Ps. By the way, I am neither a maintainer nor the creator of GnuPG or the OpenPGP standard. -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 688 bytes Desc: not available URL: From felix.klee at inka.de Sun Jan 30 12:22:24 2022 From: felix.klee at inka.de (Felix E. Klee) Date: Sun, 30 Jan 2022 12:22:24 +0100 Subject: YubiKey 5C NFC not detected References: <87r18q5j7w.fsf@inka.de> <2778274.reUcr414bH@breq> Message-ID: <87a6fda2of.fsf@inka.de> Ingo Kl?cker writes: > Are you sure "Yubico Yubi" is the correct value for the reader-port > option? It?s what is suggested in the official [Troubleshooting Issues with GPG][1]. They also suggest: Yubico Yubikey That doesn?t work either. As I realized before, their guides are not up to date. [Elsewhere][2] I found that one can scan for devices: $ gpgconf --kill gpg-agent $ ykman config usb -l OTP FIDO U2F FIDO2 OATH PIV OpenPGP YubiHSM Auth $ pcsc_scan -n Using reader plug'n play mechanism Scanning present readers... Waiting for the first reader... | That just hangs, same when prefixed with `sudo`. > Did you try without specifying this option? Yes. $ rm .gnupg/scdaemon.conf $ gpgconf --kill gpg-agent $ gpg --card-status gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device By the way, to make `ykman` see the key, I had to add a udev rule: $ cat /etc/udev/rules.d/10-security-key.rules KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0666", GROUP="users", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0407" Any idea what else I can try? [1]: https://support.yubico.com/hc/en-us/articles/360013714479-Troubleshooting-Issues-with-GPG [2]: https://blog.programster.org/yubikey-link-with-gpg From kloecker at kde.org Sun Jan 30 13:49:58 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 30 Jan 2022 13:49:58 +0100 Subject: YubiKey 5C NFC not detected In-Reply-To: <87a6fda2of.fsf@inka.de> References: <87r18q5j7w.fsf@inka.de> <2778274.reUcr414bH@breq> <87a6fda2of.fsf@inka.de> Message-ID: <1917597.fq28ylnqIZ@breq> On Sonntag, 30. Januar 2022 12:22:24 CET Felix E. Klee wrote: > Ingo Kl?cker writes: > > Are you sure "Yubico Yubi" is the correct value for the reader-port > > option? > > It?s what is suggested in the official [Troubleshooting Issues with > GPG][1]. They also suggest: > > Yubico Yubikey > > That doesn?t work either. As I realized before, their guides are not up > to date. > > Did you try without specifying this option? > > Yes. > > $ rm .gnupg/scdaemon.conf > $ gpgconf --kill gpg-agent > $ gpg --card-status > gpg: selecting card failed: No such device > gpg: OpenPGP card not available: No such device > > By the way, to make `ykman` see the key, I had to add a udev rule: > > $ cat /etc/udev/rules.d/10-security-key.rules > KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0666", GROUP="users", > ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0407" > > Any idea what else I can try? Run the following command to see which readers GnuPG's scdaemon sees: ``` $ echo scd getinfo reader_list | gpg-connect-agent --decode ``` For my YubiKey I get ``` D 1050:0407:X:0 OK ``` Instead of the "X" (which I get literally because apparently more descriptive information is missing) you will hopefully see a more descriptive string. That's the string you need to use for reader-port if you want to tell scdaemon explicitly which reader it should use. If scdaemon sees only one reader, then setting the option reader-port makes no sense. If scdaemon doesn't see your reader then it's probably not (yet) supported by GnuPG's CCID driver. Then you could try to use pcsc by adding the option disable-ccid to your scdaemon.conf. You could also try GnuPG 2.3.4. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From felix.klee at inka.de Sun Jan 30 14:37:37 2022 From: felix.klee at inka.de (Felix E. Klee) Date: Sun, 30 Jan 2022 14:37:37 +0100 Subject: YubiKey 5C NFC not detected References: <87r18q5j7w.fsf@inka.de> <2778274.reUcr414bH@breq> <87a6fda2of.fsf@inka.de> <1917597.fq28ylnqIZ@breq> Message-ID: <87y22x8hum.fsf@inka.de> Ingo Kl?cker writes: > $ echo scd getinfo reader_list | gpg-connect-agent --decode $ ykman config usb -l OTP FIDO U2F FIDO2 OATH PIV OpenPGP YubiHSM Auth $ gpgconf --kill gpg-agent $ echo scd getinfo reader_list | gpg-connect-agent --decode OK :( > If scdaemon doesn't see your reader then it's probably not (yet) > supported by GnuPG's CCID driver. Then you could try to use pcsc by > adding the option disable-ccid to your scdaemon.conf. $ echo disable-ccid >~/.gnupg/scdaemon.conf $ gpgconf --kill gpg-agent $ gpg --card-status gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device :( > You could also try GnuPG 2.3.4. Think I?ll wait until it?s in Arch. At the moment: $ gpg --version gpg (GnuPG) 2.2.32 From johanw at vulcan.xs4all.nl Sun Jan 30 15:44:36 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 30 Jan 2022 15:44:36 +0100 Subject: First Amendment and Marines? In-Reply-To: <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> Message-ID: <6092bd28-a85d-4eef-b985-79f97f32ef83@vulcan.xs4all.nl> On 29-01-2022 18:58, Robert J. Hansen via Gnupg-users wrote: > But if you're an American without EU ties, the GDPR is yet another piece > of foreign legislation we don't need to pay attention to.? And when > Europeans baldly say "the GDPR applies worldwide, you must follow it," > what we hear is "the EU overrides your silly Constitution." However, the opposite also occurs: some US companies appear to be shocked when I, as a European without any ties to the US, claim I won't comply to a DMCA request because we don't have such a law here. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Sun Jan 30 18:40:16 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jan 2022 12:40:16 -0500 Subject: First Amendment and Marines? In-Reply-To: <6092bd28-a85d-4eef-b985-79f97f32ef83@vulcan.xs4all.nl> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> <6092bd28-a85d-4eef-b985-79f97f32ef83@vulcan.xs4all.nl> Message-ID: <4e895204-aa8e-18c2-aa1a-3fdc23e6591e@sixdemonbag.org> > However, the opposite also occurs: some US companies appear to be > shocked when I, as a European without any ties to the US, claim I won't > comply to a DMCA request because we don't have such a law here. Yes! And when American companies are so foolish as to demand an EU citizen comply with a DMCA takedown notice, I encourage you to laugh at the silliness. :) From wk at gnupg.org Sun Jan 30 19:42:58 2022 From: wk at gnupg.org (Werner Koch) Date: Sun, 30 Jan 2022 19:42:58 +0100 Subject: YubiKey 5C NFC not detected In-Reply-To: <87y22x8hum.fsf@inka.de> (Felix E. Klee's message of "Sun, 30 Jan 2022 14:37:37 +0100") References: <87r18q5j7w.fsf@inka.de> <2778274.reUcr414bH@breq> <87a6fda2of.fsf@inka.de> <1917597.fq28ylnqIZ@breq> <87y22x8hum.fsf@inka.de> Message-ID: <87ee4pf4jx.fsf@wheatstone.g10code.de> Hi! On Sun, 30 Jan 2022 14:37, Felix E. Klee said: > $ echo scd getinfo reader_list | gpg-connect-agent --decode > OK scdaemon does not see any reader. That might simply due to another process which uses the reader (the yubikey tools). Using debug cardio verbose log-file /some/where/scd.log in sdameon.conf can give some insights. You should also try adding pcsc-shared into scdameon.conf - this allows the concurrent use of the reader by more than one process. > gpg (GnuPG) 2.2.32 Note that there is a bug in the reader-port implementation of 2.2.33; you better wait for 2.2.34 instead of updating to 2.2.33. Shalom-Salam, Werner p.s. I did follow the entire thread, thus I may have repeated other advices. -- 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 juergen at bruckner.email Sun Jan 30 19:15:03 2022 From: juergen at bruckner.email (Juergen M. Bruckner) Date: Sun, 30 Jan 2022 19:15:03 +0100 Subject: First Amendment and Marines? In-Reply-To: <6092bd28-a85d-4eef-b985-79f97f32ef83@vulcan.xs4all.nl> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> <9ba64ae4-7039-10c2-a127-4207e3cbd3d5@sixdemonbag.org> <6092bd28-a85d-4eef-b985-79f97f32ef83@vulcan.xs4all.nl> Message-ID: Am 30.01.22 um 15:44 schrieb Johan Wevers via Gnupg-users: > On 29-01-2022 18:58, Robert J. Hansen via Gnupg-users wrote: > >> But if you're an American without EU ties, the GDPR is yet another piece >> of foreign legislation we don't need to pay attention to.? And when >> Europeans baldly say "the GDPR applies worldwide, you must follow it," >> what we hear is "the EU overrides your silly Constitution." > > However, the opposite also occurs: some US companies appear to be > shocked when I, as a European without any ties to the US, claim I won't > comply to a DMCA request because we don't have such a law here. > With Directive 2001/29/EC, there is indeed a similar law in Europe, but it does not have the same broad scope as the DMCA. -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From angel at pgp.16bits.net Mon Jan 31 01:09:23 2022 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 31 Jan 2022 01:09:23 +0100 Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page) In-Reply-To: References: <202112020957.12700.bernhard@intevation.de> <202112031204.31216.bernhard@intevation.de> Message-ID: <9f0da7e439c7d79630c6b597187730d8554206cd.camel@16bits.net> On 2022-01-29 at 17:34 +0100, Binarus wrote: > I didn't read the wiki page yet, but I'd like to comment on that > paragraph. I agree in part, but not completely. The idea is nice, but > can't be realized in practice. > > From my personal experience, it is very hard and consumes time to > find appropriate subject lines. After all, when using OpenPGP in > business, recipients invest 5 seconds per message at maximum when > scanning the list of received messages to decide what message to read > first. "Wrong" subject lines are not helpful in this context. That > means that your suggestion may be valid for private communication, > but not for business. > > Rather, it is often good style and really simplifies things if some > important (sensitive) data is in the subject line. As an example, > imagine that you are communicating with your health insurance > company. The staff there usually is very grateful if they see your > insurance number in the subject line, plus a few keywords (in German, > for example, "K?ndigung", "Leistungsantrag" etc.). Not following this > convention costs them time and effort and is bad style. How is it that *not* having the insurance number in the subject but instead e.g. on the first line costs them time and effort? > Apart from that, you'll have some trouble yourself with that > strategy. Imagine you have to find a message you have sent two years > ago. That could be hard if you have "faked" the subject lines. > Furthermore, the recipient will hopefully answer your message one > day, and will typically do this by just hitting the "Reply" button. > That means the answer comes back with the same "fake" subject line > you originally had chosen, and that game will continue until the > communication on this subject has ceased. In the end, you have 50 > sent messages and 50 received messages with a "wrong" subject line. I agree with this, though. > Your comparison with snail mail is the right way to understand the > issue: Did you ever receive a letter from your health insurance which > carried the actual subject on the *outside* of the *envelope* > (example subject of a letter from your health insurance: "Payment for > your HIV treatment")? I didn't, and I'll have a very serious talk > with the sender if I ever do. That's a good example where it would be preferable to use a subject like "Payment for your treatment". It's probably not really required to specify in the subject line *which* kind of treatment it is. And that broad topic is probably not revealing much for an email received from "invoices at healthinsurance.com" > *Every* piece of data should be protected, especially in electronic > communication, except the transportation data which technically is > absolutely necessary to get the transport done. I agree on principle, but see below. > In the same way the postal service does not need to know the content > of a letter (including the subject) to transport it from the sender > to the recipient, SMTP servers do not need to know the subject to > transport messages. > > SMTP basically needs only the sender address (strictly looking at it, > not even that, but it is important for bounces and replies) and the > recipient address. Sad to say that SMTP servers usually dynamically > add headers during transport which already can put somebody at risk, > but I guess we'll have to live with that for the moment. > > A subject line really does not fall into the category of > transportation data. SMTP servers don't need to know it to transport > the message, and it can (and in most cases, will) contain sensitive > data. We shouldn't call something transportation data solely because > it is in a header. Nothing in the email you receive is actually required. You could have a Fully-Encrypted-Email-Messages, which on SMTP looked like: MAIL FROM:<...> RCPT TO: DATA -----BEGIN PGP MESSAGE----- hF4DCPKrKdZYGfESAQdATlsTH4qB5t6wpjKRftCMhq4BqoFa28iMd1aIDZaq710w ... -----END PGP MESSAGE----- . QUIT No plaintext at all. (Well, some Received: headers would be added, plus a Return-Path: ) You can even do that today. Your problem is that no client supports it. > I am very grateful that we can finally encrypt the subject line with > most OpenPGP implementations since several years. *Most* implementations? Could you list them? I would have thought that there are still more implementations not supporting it than supporting. > Actually, not being able to do this kept me from using PGP (in E- > Mail) for a while. Now I always encrypt the subject line, and so do > my communication partners. That's fine if you know that the other side will be able to read it (or you don't care if they cannot read it). > If there are MUAs out there which can't cope with that, refraining > from encrypting the subject would be the wrong reaction. Instead, > people using such a MUA should be educated to use another MUA. PGP > implementations have undergone changes which were much more > "breaking" than encrypted subject lines. Except there's no specification for that, so you can hardly blame them for not supporting it. There was draft-autocrypt-lamps-protected- headers, which expired 1.5 years ago. https://www.ietf.org/archive/id/draft-autocrypt-lamps-protected-headers-02.txt The more pressing issue, however, is that encrypting the subject makes non-trivial some features that the users have become used to, like listing the (decrypted) subjects of all your emails (as it now requires decrypting $N emails, which needs fetching all of them from the IMAP server, unlocking all the keys?). It also somewhat obscures the advice that "anything in the headers of the email is not protected", since it is now protected only _sometimes_. Best regards From wk at gnupg.org Mon Jan 31 08:04:03 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 31 Jan 2022 08:04:03 +0100 Subject: Backup of GPG private keys? In-Reply-To: <1311b41f5d2dc2414aa68d2df0cae4232cf6af68.camel@16bits.net> (=?utf-8?Q?=22=C3=81ngel=22's?= message of "Sun, 30 Jan 2022 04:25:24 +0100") References: <87bkzxbsqi.fsf@iki.fi> <87pmocfhvu.fsf@wheatstone.g10code.de> <1311b41f5d2dc2414aa68d2df0cae4232cf6af68.camel@16bits.net> Message-ID: <871r0ofkt8.fsf@wheatstone.g10code.de> On Sun, 30 Jan 2022 04:25, ?ngel said: > Could you elaborate? I am surely missing something. Unfortunately I can't tell you any details because the paper has not yet been published. The attack is not easy to mount but it is not entirely academic. It affects the standard for sending private keys and not any specific implementation. The OpenPGP DT knows about it for nearly a year but they are busy nitpicking on details of the 4880bis and spending way to much time handling and discussing editorial issues and non chartered features. 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 foss at morgwai.pl Mon Jan 31 15:58:22 2022 From: foss at morgwai.pl (Piotr Morgwai Kotarbinski) Date: Mon, 31 Jan 2022 21:58:22 +0700 Subject: photo-ID omitted when retrieving keys from WKD Message-ID: Hello all, I have a public key with a photo-ID uploaded to WKD at my domain and when I download it manually and import to gpg, everything works as expected: > ubuntu at sandbox-jammy:~$ mkdir curl > ubuntu at sandbox-jammy:~$ chmod 0700 curl > ubuntu at sandbox-jammy:~$ gpg --homedir curl --list-keys > gpg: keybox '/home/ubuntu/curl/pubring.kbx' created > gpg: /home/ubuntu/curl/trustdb.gpg: trustdb created > ubuntu at sandbox-jammy:~$ curl https://morgwai.pl/.well-known/openpgpkey/hu/iffe93qcsgp4c8ncbb378rxjo6cn9q6u?l=test |gpg --homedir curl --import > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 6131 100 6131 0 0 7041 0 --:--:-- --:--:-- --:--:-- 7039 > gpg: key 5EE910C88398CC40: public key "Test Email " imported > gpg: Total number processed: 1 > gpg: imported: 1 > ubuntu at sandbox-jammy:~$ gpg --homedir curl --list-keys > /home/ubuntu/curl/pubring.kbx > ----------------------------- > pub rsa3072 2022-01-31 [SC] [expires: 2024-01-31] > 23F3101D5D4428E12E6659095EE910C88398CC40 > uid [ unknown] Test Email > uid [ unknown] [jpeg image of size 3890] > sub rsa3072 2022-01-31 [E] [expires: 2024-01-31] However if I try to locate the same key automatically using WKD mechanism, then the attached photo-ID is not imported into my keyring: > ubuntu at sandbox-jammy:~$ gpg --homedir wkd --list-keys > gpg: keybox '/home/ubuntu/wkd/pubring.kbx' created > gpg: /home/ubuntu/wkd/trustdb.gpg: trustdb created > ubuntu at sandbox-jammy:~$ gpg -vv --homedir wkd --locate-keys test at morgwai.pl > gpg: using pgp trust model > gpg: error retrieving 'test at morgwai.pl' via Local: No public key > # off=0 ctb=99 tag=6 hlen=3 plen=397 > :public key packet: > version 4, algo 1, created 1643637767, expires 0 > pkey[0]: [3072 bits] > pkey[1]: [17 bits] > keyid: 5EE910C88398CC40 > # off=400 ctb=b4 tag=13 hlen=2 plen=28 > :user ID packet: "Test Email " > # off=430 ctb=89 tag=2 hlen=3 plen=468 > :signature packet: algo 1, keyid 5EE910C88398CC40 > version 4, created 1643637767, md5len 0, sigclass 0x13 > digest algo 10, begin of digest d0 92 > hashed subpkt 33 len 21 (issuer fpr v4 23F3101D5D4428E12E6659095EE910C88398CC40) > hashed subpkt 2 len 4 (sig created 2022-01-31) > hashed subpkt 27 len 1 (key flags: 03) > hashed subpkt 9 len 4 (key expires after 2y0d0h0m) > hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) > hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2) > hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) > hashed subpkt 30 len 1 (features: 01) > hashed subpkt 23 len 1 (keyserver preferences: 80) > subpkt 16 len 8 (issuer key ID 5EE910C88398CC40) > data: [3072 bits] > # off=901 ctb=d1 tag=17 hlen=3 plen=3909 new-ctb > :attribute packet: [jpeg image of size 3890] > # off=4813 ctb=89 tag=2 hlen=3 plen=468 > :signature packet: algo 1, keyid 5EE910C88398CC40 > version 4, created 1643638375, md5len 0, sigclass 0x13 > digest algo 10, begin of digest 64 cc > hashed subpkt 33 len 21 (issuer fpr v4 23F3101D5D4428E12E6659095EE910C88398CC40) > hashed subpkt 2 len 4 (sig created 2022-01-31) > hashed subpkt 27 len 1 (key flags: 03) > hashed subpkt 9 len 4 (key expires after 2y0d0h0m) > hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) > hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2) > hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) > hashed subpkt 30 len 1 (features: 01) > hashed subpkt 23 len 1 (keyserver preferences: 80) > subpkt 16 len 8 (issuer key ID 5EE910C88398CC40) > data: [3072 bits] > # off=5284 ctb=b9 tag=14 hlen=3 plen=397 > :public sub key packet: > version 4, algo 1, created 1643637767, expires 0 > pkey[0]: [3072 bits] > pkey[1]: [17 bits] > keyid: B66941040BC242DD > # off=5684 ctb=89 tag=2 hlen=3 plen=444 > :signature packet: algo 1, keyid 5EE910C88398CC40 > version 4, created 1643637767, md5len 0, sigclass 0x18 > digest algo 10, begin of digest 65 bc > hashed subpkt 33 len 21 (issuer fpr v4 23F3101D5D4428E12E6659095EE910C88398CC40) > hashed subpkt 2 len 4 (sig created 2022-01-31) > hashed subpkt 27 len 1 (key flags: 0C) > hashed subpkt 9 len 4 (key expires after 2y0d0h0m) > subpkt 16 len 8 (issuer key ID 5EE910C88398CC40) > data: [3069 bits] > gpg: pub rsa3072/5EE910C88398CC40 2022-01-31 Test Email > gpg: writing to '/home/ubuntu/wkd/pubring.kbx' > gpg: key 5EE910C88398CC40: public key "Test Email " imported > gpg: no running gpg-agent - starting '/usr/bin/gpg-agent' > gpg: waiting for the agent to come up ... (5s) > gpg: connection to agent established > gpg: Total number processed: 1 > gpg: imported: 1 > gpg: auto-key-locate found fingerprint 23F3101D5D4428E12E6659095EE910C88398CC40 > gpg: automatically retrieved 'test at morgwai.pl' via WKD > pub rsa3072 2022-01-31 [SC] [expires: 2024-01-31] > 23F3101D5D4428E12E6659095EE910C88398CC40 > uid [ unknown] Test Email > sub rsa3072 2022-01-31 [E] [expires: 2024-01-31] Is this intended or is it a bug? Is there a way to force gpg to retrieve photo-ID when using WKD? I'm using GnuPG-2.2.27 on ubuntu jammy. Or maybe there's some problem with my WKD, regardless that it works manually with curl as shown above? It was generated using the python-3 script: `./generate-openpgpkey-hu-3 -k .gnupg/pubring.kbx -m morgwai.pl -o hu` Thanks! From felix.klee at inka.de Mon Jan 31 17:06:13 2022 From: felix.klee at inka.de (Felix E. Klee) Date: Mon, 31 Jan 2022 17:06:13 +0100 Subject: YubiKey 5C NFC not detected References: <87r18q5j7w.fsf@inka.de> <2778274.reUcr414bH@breq> <87a6fda2of.fsf@inka.de> <1917597.fq28ylnqIZ@breq> <87y22x8hum.fsf@inka.de> <87ee4pf4jx.fsf@wheatstone.g10code.de> Message-ID: <875ypz3n62.fsf@inka.de> Werner Koch via Gnupg-users writes: > scdaemon does not see any reader. That might simply due to another > process which uses the reader (the yubikey tools). None the wiser: $ cat ~/.gnupg/scdaemon.conf debug cardio verbose log-file /tmp/scd.log pcsc-shared $ gpgconf --kill gpg-agent $ gpg --card-status gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device $ cat /tmp/*.log 2022-01-30 20:50:40 scdaemon[416012] listening on socket '/run/user/1000/gnupg/S.scdaemon' 2022-01-30 20:50:40 scdaemon[416012] handler for fd -1 started 2022-01-30 20:50:40 scdaemon[416012] ccid open error: skip 2022-01-30 20:50:40 scdaemon[416012] pcsc_list_readers failed: no readers available (0x8010002e) >> gpg (GnuPG) 2.2.32 > > Note that there is a bug in the reader-port implementation of 2.2.33; > you better wait for 2.2.34 instead of updating to 2.2.33. Good to know. Will keep an eye on it. Even if 2.2 doesn?t work with that YubiKey, it does work just fine with the OpenPGP smart card in my [SPR232 mod][1]. So I don?t want to loose access there. [1]: https://github.com/feklee/0.332 From andrewg at andrewg.com Mon Jan 31 17:41:32 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 31 Jan 2022 16:41:32 +0000 Subject: First Amendment and Marines? In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> Message-ID: <52469cb0-9990-4857-efd9-b982ab1d5ee5@andrewg.com> On 30/01/2022 10:12, Klaus Ethgen wrote: > > When it comes to keyservers, with the same argument you could state that > bitcoin is illegal. (No information in the key chain can be removed. And > there is even child porn inside that key chain that could never ever > again be removed!) > > There are more technologies out there where informations, once in, could > never removed again. Yes, and this is both morally and legally terrifying. The fact that nobody has yet been taken to court over this particular issue merely makes the legality of it "untested". A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon Jan 31 17:56:51 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 31 Jan 2022 16:56:51 +0000 Subject: Preventing public key upload to key-servers In-Reply-To: <62179ef0-0a20-c045-89a4-384483620852@rushpost.com> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <62179ef0-0a20-c045-89a4-384483620852@rushpost.com> Message-ID: On 29/01/2022 03:51, Shawn K. Quinn via Gnupg-users wrote: > If the server is physically in the US, administered by someone residing > in the US, is the EU really expecting US courts to enforce EU > laws/directives like the GDPR on a US citizen? The short answer is no, of course not. The practical consequence of the GDPR's "universality" is that if you want to do business in the EU, you have to comply across your worldwide operations. For mom and pop stores, this will therefore never be an issue. But for multinational companies (Google, Facebook, etc.), this has real teeth. In particular, it means that they can't hide behind "yes we broke your rules but we laundered it through another jurisdiction so you can't touch us". A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon Jan 31 18:11:52 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 31 Jan 2022 17:11:52 +0000 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: <2908b6ef-ef9c-ec1c-1a31-908dfa32522f@andrewg.com> On 29/01/2022 01:55, Johan Wevers via Gnupg-users wrote: > There are known technical issues: the HKP keyserver does not allow keys > to be removed, GDPR or not. When the keyserer operator operates outside > of the EU I don't think that is a legal problem. This is incorrect. All three of the commonly-used HKP servers can remove keys; this has been done for years to remove poison (i.e. oversized) keys that cause DoS. However doing so comes with costs. SKS does not properly support removing keys, however it is often patched to include a list of known poison keys that should be ignored. This obviously does not scale. Other keyservers (Hockeypuck and Hagrid) have proper support for removing keys. The longer-term cost is that keyserver sync (in SKS and Hockeypuck) degrades as the list of blocked keys grows. Hockeypuck caches sync failures and so (in theory) degrades more gracefully than SKS, which does not. A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon Jan 31 18:51:44 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 31 Jan 2022 17:51:44 +0000 Subject: Preventing public key upload to key-servers In-Reply-To: <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: On 28/01/2022 20:02, jonkomer via Gnupg-users wrote: >> A. G. via : >> The short answer is "no", or at best "not yet"... > > Thank you very much for the response and comprehensive > comments. > > In this case, the mail domain owner is actually the one > that needs this level of control: he insists on the ability > to positively respond to individual e-mail users' GDPR > "forget me" requests. ... > Domain owner intends to operate a "members only" public key > dissemination and fingerprint verification mechanism. When > the user is removed from the "membership", (either by the > domain owner action or by his or her own request), the mail > address (and any/all other personal data) is? deleted and > promptly removed from the publicly exposed Internet domain > presence. This sounds like a perfect use case for WKD. It is under the full control of the domain owner (the data controller), and RTBF does not arise. Publication of the key is necessary to provide the service, and the data controller deletes personal data immediately on cessation of that service. > After the user removal the domain owner is ipso facto > GDPR compliant. However, he would prefer that a naive user > (rightly or not) does not consider him unresponsive, and both > sides Both sides? > have some interest in preventing any Internet server > from keeping an active and publicly exposed user's name > and (now defunct) e-mail-address, thus indiscriminately > advertising forever the fact that John Doe was at some point > in time a member of Example.org. This is not an OpenPGP-specific concern - anyone with John Doe's name and email in their address book can potentially "leak" the fact that JD was once associated with example.com, even if he never creates a public key. These are presumably the same people that he is corresponding with using OpenPGP. GDPR actively helps you here, by ensuring that if you are corresponding with a company that does business in the EU, they must have internal processes to minimise such leaks. Otherwise, you are at the mercy of your correspondents, GDPR or not. What is to stop them posting JD's contact details on Twitter, for example? Or synchronising their address books with a badly-run cloud service? > How do individual key-server owner/operators react to > formal GDPR "forget me" requests; either by e-mail users, or > by mail domain owners? Any known legal precedents? The mail domain owner cannot make an RTBF request on behalf of a user; GDPR applies to personal data, and the domain owner is not the data owner. Hockeypuck server operators can add the fingerprint of the offending key to their block list. SKS operators have to recompile, but in theory can also comply. A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Mon Jan 31 18:53:58 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 31 Jan 2022 18:53:58 +0100 Subject: photo-ID omitted when retrieving keys from WKD In-Reply-To: References: Message-ID: <2324704.NDSbao0uJy@breq> On Montag, 31. Januar 2022 15:58:22 CET Piotr Morgwai Kotarbinski via Gnupg- users wrote: > I have a public key with a photo-ID uploaded to WKD at my domain and when I download it manually and import to gpg, everything works as expected: [...] > However if I try to locate the same key automatically using WKD mechanism, then the attached photo-ID is not imported into my keyring: [...] > Is this intended or is it a bug? Yes, this is intended. Keys retrieved via WKD are always imported with the equivalent of the import filter {keep-uid=}. The reasoning is that only user ids matching the email address used to retrieve the key via WKD can be somewhat trusted (if you trust the people running the WKS). Any other user id including photo ids on the key could be fake, i.e. you could easily add the photo of another person as photo id to your key. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Mon Jan 31 19:01:28 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 31 Jan 2022 18:01:28 +0000 Subject: First Amendment and Marines? In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> <979d3320-a089-dc7b-1b52-0e87d5dc74d8@sixdemonbag.org> Message-ID: I go away for the weekend, and my mailbox catches fire... ;-) On 29/01/2022 16:38, jonkomer via Gnupg-users wrote: > (a) Unfortunately, OpenPG email encryption is incompatible > with GDPR and should not be used by those that either want > or need to be GDPR compliant. This is not so; the use of email encryption *improves* GDPR compliance. > (b) GDPR appears to be a topic that, for some strange reason, > elicits emotional reactions by the OpenPG creators and > maintainers. GDPR elicits interesting reactions in general! ;-) > (c) GPG and OpenPG appear to be very much US-centric > endevours. That fact ought to be taken into account by the > new users. On the contrary, Europe is (in my experience) over-represented in the OpenPGP development community, and there has been extensive discussion of its implications for PGP both in this group and elsewhere. > If the ultimate goal of OpenPG is the wider adaption of > encrypted e-mail, finding technical means to make it usable > by those that *wish to be GDPR compliant* - without forcing > such MO on everyone - appears to be a worthwhile effort. Agreed in general, however I'm not sure what you mean by "forcing such MO on everyone". A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Jan 31 20:06:53 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 31 Jan 2022 20:06:53 +0100 Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page) In-Reply-To: <9f0da7e439c7d79630c6b597187730d8554206cd.camel@16bits.net> (=?utf-8?Q?=22=C3=81ngel=22's?= message of "Mon, 31 Jan 2022 01:09:23 +0100") References: <202112020957.12700.bernhard@intevation.de> <202112031204.31216.bernhard@intevation.de> <9f0da7e439c7d79630c6b597187730d8554206cd.camel@16bits.net> Message-ID: <874k5jenci.fsf@wheatstone.g10code.de> On Mon, 31 Jan 2022 01:09, ?ngel said: > Nothing in the email you receive is actually required. You could have a > Fully-Encrypted-Email-Messages, which on SMTP looked like: > > MAIL FROM:<...> > RCPT TO: > DATA > > > . > QUIT > > > No plaintext at all. (Well, some Received: headers would be added, plus > a Return-Path: ) You can even do that today. > > Your problem is that no client supports it. Your problem is that the entire business world would immediatley stop grinding. Mail ist not just a toy for privacy geeks but the glue which connects all kind of processes. If you don't need this just switch to to your favorite chat protocol. 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 jonkomer at yandex.com Mon Jan 31 22:39:18 2022 From: jonkomer at yandex.com (jonkomer) Date: Mon, 31 Jan 2022 14:39:18 -0700 Subject: Preventing public key upload to key-servers In-Reply-To: References: <3a51df73-8e2e-40d3-61ad-7842a5aa0190@yandex.com> <6e1e6933-4761-5981-b0b9-eb48a9007a78@yandex.com> Message-ID: <4d179670-3fd6-fd38-dba9-4ff2eecbe04c@yandex.com> > This sounds like a perfect use case for WKD.... You are correct. But the reason for my original post was not to find better ways of communication mechanics while the relationship exists, it was specific and quite narrow: how can both sides do all they reasonably can in order to avoid making it public knowledge that the relationship existed *after it has been dissolved*. There is significant difference between a one-time "third-party" correspondent misusing his knowledge of the relationship after it has been dissolved, from that same knowledge being published in perpetuity via a simple, automated Internet query. Specifically, the question was if there is any mitigation against the action of an uninformed (or, perhaps by a stretch, malicious?) correspondent adding signatures and uploading the key to the network of synchronizing pubkey servers. Well, there is none. > Europe is (in my experience) over-represented in the > OpenPGP development community Then I stand corrected. (My impression was based only on the "US pop-culture coloured" and clearly emotional response to the mere mention of GDPR). Jon K. From andrewg at andrewg.com Mon Jan 31 22:47:59 2022 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 31 Jan 2022 21:47:59 +0000 Subject: Preventing public key upload to key-servers In-Reply-To: <4d179670-3fd6-fd38-dba9-4ff2eecbe04c@yandex.com> References: <4d179670-3fd6-fd38-dba9-4ff2eecbe04c@yandex.com> Message-ID: <023D2A5F-70CE-4430-B825-F09C5CA7A29C@andrewg.com> > On 31 Jan 2022, at 21:39, jonkomer wrote: > > There is significant difference between a one-time > "third-party" correspondent misusing his knowledge of > the relationship after it has been dissolved, from > that same knowledge being published in perpetuity via > a simple, automated Internet query. Are you worried about people discovering this relationship, or confirming a suspected relationship? A From jonkomer at yandex.com Mon Jan 31 23:29:45 2022 From: jonkomer at yandex.com (jonkomer) Date: Mon, 31 Jan 2022 15:29:45 -0700 Subject: "Are You Now or Have You Ever Been..." In-Reply-To: <023D2A5F-70CE-4430-B825-F09C5CA7A29C@andrewg.com> References: <4d179670-3fd6-fd38-dba9-4ff2eecbe04c@yandex.com> <023D2A5F-70CE-4430-B825-F09C5CA7A29C@andrewg.com> Message-ID: <30327f6c-a302-cf00-72ec-dc9254a1ae8e@yandex.com> > Are you worried about people discovering this relationship, or confirming a suspected relationship? Confirming it, possibly many years after it has been dissolved. Future is the key-word here. In that context, then-current response of a key-server query on "" could be much more deleterious to John than the evidence given to the tribunal by Jane Doe that she exchanged e-mails with john.doe at example.org way back in 2022. Jon K.