From have at anonymous.sex Thu Jan 2 00:57:25 2025 From: have at anonymous.sex (have at anonymous.sex) Date: Wed, 1 Jan 2025 23:57:25 +0000 Subject: Betamax v. VHS, and the future of PQ-PGP Message-ID: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> A disquisition could here ensue on the long-term security reasons why everyone should start using ky1024_cv448 encryption subkeys RIGHT NOW. https://en.wikipedia.org/wiki/Massive_Data_Repository But if you understand security well enough to read this list, why waste your time? Instead, let?s talk about format wars and network effects. Fifty years ago, a format war was brewing between the videocassette formats Betamax and VHS. Today, you can still find people debating on the Internet whether or not Betamax was technically superior, and why VHS won, and so forth. For anyone who didn?t try both in the late 1970s to early 1980s, all that?s clear is that VHS (0) won decisively when it attained (1) network effects in the (2) consumer market. The format war concluded when Sony, the producer of Betamax, adopted VHS themselves. As we now enter the year 2025, a format war is brewing in PGP. This message is not the place for me to opine on the technical merits of LibrePGP v. IETF OpenPGP, or whose fault the standards split is, or whether so-and-so is a very mean person or not. Today, here and now, I am more worried about something else. The standards split will foreseeably lead to a world in which your choice of \*PGP software determines with whom you can exchange post-quantum encrypted mail. The lowest common denominator will remain plain ECC or RSA, as it is today. That?s bad. For the sake of user security, one side or the other needs to win so decisively that its standard is universally adopted. Ever since 1993, PGP has been driven by its individual users. Although corporate security use is nice and important, and GnuPG has a key role in securing the open-source software supply chain, it?s reasonable to anticipate that the format war will be decided by keys in the wild: Not merely which side has more users with keys, but which side has more significant keys for people *you* want to talk to privately. The first mover has an advantage here... In terms of user base, GnuPG was the first major \*PGP implementation to offer post-quantum encryption that you can actually use *right now*. Although this feature is still only in a ?public testing? branch, GnuPG since v2.5.1 (2024-09-12) has supported ?the final FIPS-203 and LibrePGP specifications?.[0] For a \*PGP implementation, the long-term stability of keys and messages is obviously of paramount importance. ...and the first mover deserves to win on that basis alone. In 2025, it is *unethical and irresponsible* to publish any encryption software or offer an encrypted communication service that does not support post-quantum cryptography. It?s interesting to see who?s been on top of this?or not. If, after the long-delayed US NIST standards process, you offer encryption without PQ crypto as we enter 2025, then you should delete your git repositories and stop making crypto. Most software features are a matter of user patience for added happiness. PQC is a safety issue. It?s a long-term safety issue that most users do not understand, and do not know how to evaluate. The onus is on cryptographic software developers. For better or for worse, everyone knew since 2022 that Kyber probably would be declared The Standard. A draft standard was available in 2023, and a final standard in 2024. There is no excuse to fail to offer users post-quantum protection in 2025. GnuPG couldn?t move ahead with ?nonstandard? PQC, as some others did with sntrup or Classic McEliece: It needs to maintain stable long-term support for keys and messages. It had draft Kyber support in May 2024, and final standard support in September, 30 days after the final standard was published. That?s how to protect users. So please, let?s see some usage. Not only will that improve security, but it will establish a user base of keys in the wild?thus encouraging user demand for compatibility with GnuPG. ### # Addendum In preparation to send this message, I attempted to upload a post-quantum key created with GnuPG v2.5.1 to keys.openpgp.org. The result of the POST to : >HTTP/2 400 >server: nginx/1.18.0 >date: Wed, 01 Jan 2025 23:02:25 GMT >content-type: text/html; charset=utf-8 >content-length: 1839 >[...] > >[...] >

Error: Parsing of key data failed.

>[...] I promptly reached out to support at keys.openpgp.org to ask when the infrastructure will support distribution of these keys to help users protect their long-term security. I anticipate that the real answer will depend on when there are significant numbers of people trying to distribute their v5 packet format keys. ### [0] https://lists.gnupg.org/pipermail/gnupg-announce/2024q3/000485.html -- # Remember these on Wednesday, January 15, 2025: https://web.archive.org/web/19971024171609/http://www.eff.org/blueribbon.html https://web.archive.org/web/19971114041230/http://www.eff.org/pub/Legal/Cases/ACLU_v_Reno/19970626_eff_cda.announce https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/23-1122.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri Jan 3 01:25:01 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 2 Jan 2025 19:25:01 -0500 Subject: Betamax v. VHS, and the future of PQ-PGP In-Reply-To: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> Message-ID: > A disquisition could here ensue on the long-term security reasons why > everyone should start using ky1024_cv448 encryption subkeys RIGHT NOW. This could only be true if everyone holds to a threat model in which their data being collected by the MDR and potentially decrypted by a First World nation-state actor is a risk that needs mitigation. Most of us do not. If you're a Linux distribution that uses a new distro signing key every year, then who really cares if someone in ten years breaks this year's key? What will they do with it, release a kernel patch for a system so old no one is using it and forge a timestamp so old everyone wonders why no one ever saw this patch before? MDRs are definitely a risk for some people and groups. They are not a universal risk necessitating immediate change. Few things are. Don't pull a Chicken Little, please. The sky is not falling. Claims to the contrary are unwise, scaremongering, and unprofessional. > Fifty years ago, a format war was brewing between the videocassette > formats Betamax and VHS... Betamax and VHS were competing for the pool of money found in the home video recorder market. The market was posed for explosive growth, and whoever became the dominant role in the early moments would reap more from the ensuing explosion. Those were the incentives driving action. You are describing the battle; I am describing why the battle existed. None of this applies to GnuPG. GnuPG is not competing for a pool of money. It seeks to be a high quality implementation of the RFC4880 standard and subsequent LibrePGP standards. That's it. It's not in competition with any other group, not BouncyCastle, not Sequoia, nothing. It's in competition with itself. So long as Werner sees merit in the LibrePGP standard, he'll keep working to provide a high quality implementation of it. > The standards split will foreseeably lead to a world in which your > choice of \*PGP software determines with whom you can exchange post- > quantum encrypted mail. Ludicrous. Absurd. Ridiculous. These are not words I use lightly. These are words I use because this claim is all of those. Assuming you're right and the worst case scenario does come to pass and your choice of software determines with whom you can communicate, well... ... how is that different from today? To demonstrate, this message is signed with my S/MIME certificate. I use Thunderbird. It lets me easily choose between competing email cryptography packages. If I have to add a third possible suite, I'm sure Thunderbird will make that easy, too. I'm sure you've noticed it wasn't any inconvenience for you to verify my signature, either. >?The lowest common denominator will remain plain ECC or RSA, as it > is today.? That?s bad. Why? Breaking RSA-4096 via Shor's algorithm is straight out of science fiction. It requires 8k qubits for the computation alone: once you take into account error correction, 40k or more qubits, all in an ensemble with a decoherence time orders of magnitude beyond what we have today. Go, check out how many qubits we have today, and project out into the future how long we have. You are looking at Goddard's rocket and talking about the urgent need to establish our mining claims in the asteroid belt right now before all the good sites are taken. Relax. Slow down. Goddard's rocket is really cool and yes, someday we'll be living in The Expanse mining asteroids. But that's a long way off. Incidentally, I call dibs on Cruithe. > In 2025, it is *unethical and irresponsible* to publish any encryption > software or offer an encrypted communication service that does not > support post-quantum cryptography. Let me get this straight: you believe Signal is acting unethically and irresponsibly by giving people a superb and secure alternative to SMS messaging, just because they don't support PQC. You literally believe that. I hope to be as unethical and irresponsible as them. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4583 bytes Desc: S/MIME Cryptographic Signature URL: From jcb62281 at gmail.com Fri Jan 3 02:31:43 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 2 Jan 2025 19:31:43 -0600 Subject: deflating heffalumps (was: Betamax v. VHS, and the future of PQ-PGP) In-Reply-To: References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> Message-ID: <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> On 1/2/25 18:25, Robert J. Hansen via Gnupg-users wrote: > [...] > >> ?The lowest common denominator will remain plain ECC or RSA, as it > > is today.? That?s bad. > > Why?? Breaking RSA-4096 via Shor's algorithm is straight out of > science fiction.? It requires 8k qubits for the computation alone: > once you take into account error correction, 40k or more qubits, all > in an ensemble with a decoherence time orders of magnitude beyond what > we have today. *THANK* *YOU* I have been looking for hard numbers for the applicability of Shor's algorithm to RSA for a long time.? You have just provided the first hard numbers I have seen.? (I knew that at least 4096 qubits would be needed to hold a result, but apparently it needs far more than that.) I have also long suspected that, while RSA key lengths beyond 4096 bits have diminishing returns against conventional computing, they may be more secure against quantum computing, perhaps even with increasing returns. Also, can you cite a good source for how Shor's algorithm scales?? And how do analogous attacks on elliptic curve cryptosystems scale?? Thanks in advance. -- Jacob From rjh at sixdemonbag.org Fri Jan 3 03:47:44 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 2 Jan 2025 21:47:44 -0500 Subject: deflating heffalumps In-Reply-To: <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> Message-ID: <5873f67f-9cd7-4266-b4fe-9ad74aab0c21@sixdemonbag.org> > I have been looking for hard numbers for the applicability of Shor's > algorithm to RSA for a long time. They're hard to come by, because we mostly only know theoretical limits. It requires a flat minimum, last I checked, of quantum gates on the order of (lg N)^2(lg lg N)(lg lg lg N) to run the algorithm, more to store a result, and so on. Turns out I misremembered the equation for breaking RSA via Shor: it's not RSA-N requires 2N+1 qubits, it's 5N+1 qubits for any realistic N. I regret my error. (Cite will appear later in this email.) As the size of the ensemble increases, so too does the risk of error. At factoring 15 you have little risk of error; at a 4096-bit number it's enormous and the number of qubits you're wasting on error correction goes through the roof. And since the larger the ensemble the larger it takes to make the ensemble, so too do your coherency times have to grow: if your ensemble decoheres before you're done assembling it, you're out of luck. The engineering challenges involved are far and away the greatest humanity has ever imagined. > I have also long suspected that, while RSA key lengths beyond 4096 bits > have diminishing returns against conventional computing, they may be > more secure against quantum computing, perhaps even with increasing > returns. Following the (very rough) rule of thumb that each additional bit requires two additional qubits, then yes, RSA can in some sense be viewed as post-quantum already, since you can ratchet its difficulty up arbitrarily to whatever level of quantum resistance you want. Afraid of an adversary with science fiction hardware and a 20kbit ensemble? Use RSA-16384 and sleep easy. I am wholly in favor of research into PQC and encourage the adoption of PQC where appropriate. However, I am also wholly in favor of thinking deeply on the words "where appropriate". > Also, can you cite a good source for how Shor's algorithm scales? https://arxiv.org/pdf/quant-ph/9602016 is the standard paper. I seem to recall we've improved on it slightly since, but not by much. >?And how do analogous attacks on elliptic curve cryptosystems scale? My understanding (which is limited: I'm not Scott Aaronson) is that Shor's algorithm, expressed in its most generic form, applies to any hidden-subgroup problem. That means discrete logs will fall to it in a similar way. I can't guarantee the 5N+1 rule will hold true, but I would definitely expect a kN+c rule with small values for k and c. > Thanks in advance. Sure! Hope this helps. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Jan 3 03:57:46 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 2 Jan 2025 21:57:46 -0500 Subject: deflating heffalumps In-Reply-To: <5873f67f-9cd7-4266-b4fe-9ad74aab0c21@sixdemonbag.org> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> <5873f67f-9cd7-4266-b4fe-9ad74aab0c21@sixdemonbag.org> Message-ID: <405b517e-cf90-4556-a16e-ebe118e6c064@sixdemonbag.org> > Following the (very rough) rule of thumb that each additional bit > requires two additional qubits... Five. Five additional qubits. Apparently the wrong constant is stuck in my head, I'm sorry. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Fri Jan 3 04:43:20 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 2 Jan 2025 21:43:20 -0600 Subject: deflating heffalumps In-Reply-To: <5873f67f-9cd7-4266-b4fe-9ad74aab0c21@sixdemonbag.org> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> <5873f67f-9cd7-4266-b4fe-9ad74aab0c21@sixdemonbag.org> Message-ID: <5ac32cdf-caa6-4313-a34d-b0690b2ce14b@gmail.com> On 1/2/25 20:47, Robert J. Hansen wrote: > [...] > >> I have also long suspected that, while RSA key lengths beyond 4096 >> bits have diminishing returns against conventional computing, they >> may be more secure against quantum computing, perhaps even with >> increasing returns. > > Following the (very rough) rule of thumb that each additional bit > requires two additional qubits, then yes, RSA can in some sense be > viewed as post-quantum already, since you can ratchet its difficulty > up arbitrarily to whatever level of quantum resistance you want. > Afraid of an adversary with science fiction hardware and a 20kbit > ensemble? Use RSA-16384 and sleep easy. Do I understand correctly that, while the complexity of conventional factoring scales with a logarithm of RSA key length, Shor's algorithm has a space requirement that scales linearly, but the engineering challenges implied by that linear growth scale exponentially? Examples from Wikipedia ("Key size") include a 3072-bit RSA key having a 2**128 work factor, but reaching 2**256 against /conventional/ computing requires a 15360-bit RSA key.? On the other hand, those same RSA keys would require 15k and 75k qubits, respectively?? Are those figures including error correction or /before/ error correction? > I am wholly in favor of research into PQC and encourage the adoption > of PQC where appropriate. However, I am also wholly in favor of > thinking deeply on the words "where appropriate". Agreed.? I also suspect that we may have practically-relevant PQC right under our noses, right now:? RSA. >> Also, can you cite a good source for how Shor's algorithm scales? > > https://arxiv.org/pdf/quant-ph/9602016 is the standard paper. I seem > to recall we've improved on it slightly since, but not by much. Thank you.? I will enjoy reading that later. >> ?And how do analogous attacks on elliptic curve cryptosystems scale? > > My understanding (which is limited: I'm not Scott Aaronson) is that > Shor's algorithm, expressed in its most generic form, applies to any > hidden-subgroup problem. That means discrete logs will fall to it in a > similar way. I can't guarantee the 5N+1 rule will hold true, but I > would definitely expect a kN+c rule with small values for k and c. Do the mathematical complexities that prevent conventional computing from making short work of 256-bit ECC keys also affect Shor's algorithm? If not, that would mean that RSA is actually /stronger/ against future threats and TLS should be moving back to RSA and Diffie-Hellman posthaste. -- Jacob From rjh at sixdemonbag.org Fri Jan 3 05:59:40 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 2 Jan 2025 23:59:40 -0500 Subject: deflating heffalumps In-Reply-To: <5ac32cdf-caa6-4313-a34d-b0690b2ce14b@gmail.com> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> <5873f67f-9cd7-4266-b4fe-9ad74aab0c21@sixdemonbag.org> <5ac32cdf-caa6-4313-a34d-b0690b2ce14b@gmail.com> Message-ID: <9b0e67f4-fc1b-4a69-ab67-f287a9fbc95f@sixdemonbag.org> > Do I understand correctly that, while the complexity of > conventional factoring scales with a logarithm of RSA key length, > Shor's algorithm has a space requirement that scales linearly, but > the engineering challenges implied by that linear growth scale > exponentially? The keyspace equivalency is made under the assumption the attacker is using the generalized number field sieve. It's unsurprising for work factors to be different for different algorithmic approaches. Your conclusion is sound but please be careful not to draw inferences about one approach from the behavior of the other. > Are those figures including error correction or /before/ error > correction? Before. > Agreed. I also suspect that we may have practically-relevant PQC > right under our noses, right now: RSA. Well, RSA is definitely quantum resistant. McEliece, another veteran algorithm, is widely believed to be truly post-quantum. > Do the mathematical complexities that prevent conventional > computing from making short work of 256-bit ECC keys also affect > Shor's algorithm? My understanding is "no". > If not, that would mean that RSA is actually /stronger/ against > future threats and TLS should be moving back to RSA and Diffie- > Hellman posthaste. The US government's belief is that RSA-3072 will be sufficient for protection of Top Secret/SCI data for the next twenty-five years. (How do I know twenty-five years? Because whenever a document is classified, it gets an automatic declassification date. The default declassification date at the TS level is twenty-five years. So if NSA says TS/SCI data today may be protected with RSA-3072, it follows they don't believe quantum computing will break RSA-3072 for at least twenty-five years.) https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF From have at anonymous.sex Fri Jan 3 19:16:11 2025 From: have at anonymous.sex (have at anonymous.sex) Date: Fri, 3 Jan 2025 18:16:11 +0000 Subject: GnuPG meets the standard of care set by Signal (Re: Betamax v. VHS, and the future of PQ-PGP) In-Reply-To: References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> Message-ID: <44d47cb3-0050-a956-97be-df6c6ab4d0f5@anonymous.sex> On Thu, 2 Jan 2025 19:25:01 -0500, Robert J. Hansen wrote: >Breaking RSA-4096 via Shor's algorithm is straight out of science >fiction. No, *this* is science fiction: It?s been known since 1977 that factoring is merely an O(log n) problem, easy-peasy, if you have a (classical) computer with infinitely large registers. I guess the algorithm probably just needs a few tweaks to be practical. https://dspace.mit.edu/bitstream/handle/1721.1/148919/MIT-LCS-TM-091.pdf >>In 2025, it is *unethical and irresponsible* to publish any encryption >>software or offer an encrypted communication service that does not >>support post-quantum cryptography. > >Let me get this straight: you believe Signal is acting unethically and >irresponsibly by giving people a superb and secure alternative to SMS >messaging, just because they don't support PQC. > >You literally believe that. > >I hope to be as unethical and irresponsible as them. Signal is acting ethically and responsibly: They have had hybrid-PQC fully deployed to all Signal users for more than a year! You literally believe a non-fact-based argument. Please live up to your stated hope: The PQXDH Key Agreement Protocol https://signal.org/docs/specifications/pqxdh/ >PQXDH provides post-quantum forward secrecy... The PQXDH protocol has been formally verified: https://www.usenix.org/conference/usenixsecurity24/presentation/bhargavan https://inria.hal.science/hal-04604518v2 It was widely publicized and discussed, e.g.: https://news.ycombinator.com/item?id=37571919 Version 1 of PQXDH was published 2023-05-24, almost a full year before GnuPG first added unstable PQC support. https://web.archive.org/web/20230919172437/https://signal.org/docs/specifications/pqxdh/ PQXDH was deployed for real users by September 2023, almost a year before GnuPG v2.5.1, with a roadmap for enforcing it in *all* chats by Signal users: Quantum Resistance and the Signal Protocol ehrenkret on 19 Sep 2023 https://signal.org/blog/pqxdh/ >Our new protocol is already supported in the latest versions of >Signal?s client applications and is in use for chats initiated after >both sides of the chat are using the latest Signal software. In the >coming months (after sufficient time has passed for everyone using >Signal to update), we will disable X3DH for new chats and require PQXDH >for all new chats. Of course, due to its need for stability of messages and keys, GnuPG had to wait for NIST to publish a final standard. Signal could use pre-standard Kyber for its hybrid PQC in 2023?just as OpenSSH could use ?nonstandard? sntrup+x25519 as it did from v8.9 (2022-02-23) , and it did by default from v9.0 (2022-04-08) . GnuPG has different design constraints. The foregoing timeline comparison MUST NOT be taken as a criticism of GnuPG. The same above-linked Signal blog post has a well-balanced view of if or when quantum computers will break ECC/RSA; I agree with this quote: >The timeline for when a sufficiently powerful quantum computer may be >created is a matter of great debate. On the low end, some argue it is >only a couple of years away. On the high end some say 30+ years, and >there are even those who assert that we may never solve the challenges >necessary to make a quantum computer with enough coherent qubits to >break the current public key cryptosystems. The middle ground seems to >be around the 5 to 10 year time horizon. We are not in a position to >judge which timeline is most likely, but we do see a real and growing >risk which means we need to take steps today to address the future >possibility of a large enough quantum computer being created. By comparison, Matrix doesn?t care: Add support for PQXDH #120 [Draft] Jan 30, 2024 https://github.com/matrix-org/vodozemac/pull/120 As of today, 2025-01-03, that PR is still at ?Draft? status, and it has had no substantive activity since it was opened 2024-01-30: https://web.archive.org/web/20250103165525/https://github.com/matrix-org/vodozemac/pull/120 That?s exemplary of what I meant with my harsh criticism of developers who fail to protect users. I criticize Signal for tying users to phone numbers, and I do not use Signal for that reason. But at least, they care about the long-term security of encrypted messages! They demonstrably care about that: The deployment timeline of PQXDH proves it. It should be the minimum standard of care. At this late date, as we enter 2025, all else is crypto-negligence. Thus, I thank you for invoking an appeal to authority with Signal as your argument?and I thank the GnuPG developers for publishing GnuPG v2.5.1 only a month after NIST published FIPS-203. Given GnuPG?s need for forward compatibility, they meet the standard of care set by Signal. >If you're a Linux distribution that uses a new distro signing key every >year, then who really cares if someone in ten years breaks this year's >key? Please do not misdirect. My message clearly pertained only to encryption. We all know the difference between encryption and digital signatures. Although there are digital signature use cases requiring long-term security against a potential QC attacker, most do not, as the example you gave does not. For now, I?m fine with with ECC signatures and ECC+Kyber1024 encryption. That?s exactly what GnuPG has offered on the 2.5 branch since 2024-09-12. >This could only be true if everyone holds to a threat model in which >their data being collected by the MDR and potentially decrypted by a >First World nation-state actor is a risk that needs mitigation. Most >of us do not. The entire concept of dragnet mass-surveillance is that this is *everyone?s* threat model. And the set of all PGP users is a small minority easily targeted for retrospective decryption. -- # Remember these on Wednesday, January 15, 2025: https://web.archive.org/web/19971024171609/http://www.eff.org/blueribbon.html https://web.archive.org/web/19971114041230/http://www.eff.org/pub/Legal/Cases/ACLU_v_Reno/19970626_eff_cda.announce https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/23-1122.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From have at anonymous.sex Fri Jan 3 19:29:20 2025 From: have at anonymous.sex (have at anonymous.sex) Date: Fri, 3 Jan 2025 18:29:20 +0000 Subject: Infrastructure support for GnuPG post-quantum keys (Re: Betamax v. VHS, and the future of PQ-PGP) In-Reply-To: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> Message-ID: <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> This is a followup on infrastructure support for PQ-PGP keys. On Wed, 1 Jan 2025 23:57:25 +0000, have at anonymous.sex wrote: >I attempted to upload a post-quantum key created with GnuPG v2.5.1 to >keys.openpgp.org. [...] I promptly reached out to support at keys.openpgp.org >to ask when the infrastructure will support distribution of these keys >to help users protect their long-term security. The reply 13 hours later made it clear that rejection of my key was intentional, due to v5 packets being ?nonstandard? and GnuPG being not ?cooperative?. I won?t ambush a volunteer answering support@ for a free keyserver, but I will publicly quote my own reply below. There has been no further response in the past 25 hours. In any discussion of this issue, *please* be cogent and courteous, and focus on user security. I?m not married to GnuPG?but insofar as I can tell, GnuPG with its ?nonstandard? v5 packets is currently the only free software option for post-quantum encrypted mail. What?s really important? ### Date: Thu, 2 Jan 2025 17:29:20 +0000 From: have at anonymous.sex To: [REDACTED] Subject: Re: GnuPG post-quantum key upload failed. Message-ID: <69f5aa5e-0378-8956-bdcc-32c9949ed3e9 at anonymous.sex> Thanks for your reply. >>When will the keyserver support distribution of these keys to assist >>users in protecting their long-term security? > >[REDACTED] If your org doesn?t want to distribute my v5 packet key with post-quantum subkey, would you please recommend a v6 packet implementation with not less than ky1024_cv448 security, which I can use *right now* and recommend to others? (Does keys.openpgp.org support v6 packet keys?) I don?t know Werner Koch or any of the other involved personalities. I?ve sometimes casually read IETF WG mail. I have not yet formally reviewed the differences between LibrePGP (packet v5) and IETF OpenPGP (packet v6), which is more difficult because the IETF committee rewrote the standard instead of revising it. I presume that all parties on both sides are basically competent at the design of cryptographic protocols. My perspective is that of an advanced user who practically has RFC 4880 memorized, who has tutored individuals gratis in PGP/GnuPG usage for >25 years, and who is very worried about the potential long-term security threat of quantum computing. Now a very frustrated user, being pushed to one side by default: 2025-01-01: Betamax v. VHS, and the future of PQ-PGP https://lists.gnupg.org/pipermail/gnupg-users/2025-January/067441.html This is not a nice wishlist feature that can wait. I sometimes try to remember what messages I sent with RSA4096 decades ago, and wonder if the keys will be factored by any QC attacker with covert interception and long-term data retention; you? https://www.technologyreview.com/2021/11/03/1039171/hackers-quantum-computers-us-homeland-security-cryptography/ https://en.wikipedia.org/wiki/Massive_Data_Repository https://microblog.cr.yp.to/1544456469038645248/index.html#1544469614133800960 Nor should it wait. The NIST PQC process was so slow that when the final standard was published in August, everyone had had almost two years to get ready for what everyone pretty much knew would be Kyber. I take it as ?we care about user security? that GnuPG v2.5.1 release notes claimed final standard support exactly 30 days after NIST published the standard, based on draft standard code that was in active testing for months before this. https://lists.gnupg.org/pipermail/gnupg-announce/2024q3/000485.html As it is, the NIST process was so tied up in red tape and personality conflicts that I?m *ashamed* that no one (including myself) was even less ?cooperative? than WK; after all, ?cypherpunks write code? and do not wait for interminable committees. That is the perspective of a user who is resolved aggressively to stop using non-PQ encryption in 2025, but also does not want to cease communicating with other human beings. With all due apologies for the long message: This is too important an issue to continue being quiet about. -- # Remember these on Wednesday, January 15, 2025: https://web.archive.org/web/19971024171609/http://www.eff.org/blueribbon.html https://web.archive.org/web/19971114041230/http://www.eff.org/pub/Legal/Cases/ACLU_v_Reno/19970626_eff_cda.announce https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/23-1122.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri Jan 3 23:13:50 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 3 Jan 2025 17:13:50 -0500 Subject: GnuPG meets the standard of care set by Signal (Re: Betamax v. VHS, and the future of PQ-PGP) In-Reply-To: <44d47cb3-0050-a956-97be-df6c6ab4d0f5@anonymous.sex> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <44d47cb3-0050-a956-97be-df6c6ab4d0f5@anonymous.sex> Message-ID: <0b418d69-5fef-4e42-b030-0ad809f6993f@sixdemonbag.org> >> Breaking RSA-4096 via Shor's algorithm is straight out of science >> fiction. > > No, *this* is science fiction: I stand by my statement. RSA-4096 via Shor's requires science fiction level technology advances. > Signal is acting ethically and responsibly:? They have had hybrid-PQC > fully deployed to all Signal users for more than a year!? You literally > believe a non-fact-based argument.? Please live up to your stated hope: There are several responses here: 1. I wasn't aware Signal was transitioning to PQC: thank you for that. 2. Do me the courtesy of taking my argument seriously, please, as I am with you. A serious response would have been, "Signal is actually transitioning to PQC, so that's a nonissue. But do I believe SSL.com is acting unethically and irresponsibly by selling S/MIME encryption and signing certificates that aren't PQC? Yes. I believe the same about NaCl and Sodium, since they're not yet deploying PQC. I believe the same about projects that rely on NaCl or Sodium to provide cryptographic primitives. It's a long list. I believe they're acting unethically and irresponsibly." Building the strongest possible version of someone else's argument and engaging with that -- as I am attempting to do with you -- is called "steelmanning", and is seen as a courtesy among serious people. > The foregoing timeline comparison MUST NOT be taken as a criticism of GnuPG. On the one hand, thank you for being clear you're not criticizing GnuPG. On the other, my experience on this list has shown me people interested in criticizing GnuPG will not be dissuaded by such imperatives. > The same above-linked Signal blog post has a well-balanced view of if or > when quantum computers will break ECC/RSA; I agree with this quote: I don't doubt your sincerity. I do doubt your understanding. See next response. >> to be around the 5 to 10 year time horizon.? We are not in a position >> to judge which timeline is most likely, but we do see a real and >> growing risk which means we need to take steps today to address the >> future possibility of a large enough quantum computer being created. Signal is only saying their risk model requires them to take steps to address a future possibility. GnuPG *has no risk model*. GnuPG provides a toolbox by which to implement the LibrePGP and RFC4880 standards. Which of those tools are ultimately utilized depends on each user's particular threat model. GnuPG imposes a truly minimalist set of policies (like not supporting RSA past 4kbit). Beyond that, GnuPG is utterly silent on how users should employ the provided tools. The defaults are sane: that's all the policy we promise. Sort of like NaCl and Sodium, come to think of it. > It should be the minimum standard of care.? At this late date, as we > enter 2025, all else is crypto-negligence.? Thus, I thank you for > invoking an appeal to authority with Signal as your argument? That wasn't an appeal to authority. It was pointing out the logical consequence of your argument: there exist a *vast number* of communications security projects that are improving the lives of millions worldwide, and for you to write them all off as unethical just because they're not using CRYSTALS-Kyber is childish. Steelman the argument. Engage the strongest version of what someone says. Or don't. Up to you. > Please do not misdirect.? My message clearly pertained only to > encryption. That was not how I read it. If you're now clarifying that you only mean asymmetric encryption and/or key negotiation, I'm happy to stipulate I misread. Accusing me of misdirection is just rude. Please note I've accused you of nothing except holding foolish positions. >?We all know the difference between encryption and digital > signatures. Really? What is it? I'm not kidding. Every asymmetric encryption algorithm I'm aware of is convertible to a digital signature algorithm. Encrypt using an RSA public key and you encrypt; encrypt with a private key and you sign. Look at discrete logs one way and you get Elgamal encryption and/or Diffie-Hellman; look at them another and you get Elgamal signatures; add arbitrary constraints and you get the Digital Signature Algorithm. Shake a bag of CRYSTALS and out falls Kyber; keep shaking and out falls Dilithium. You appear to be saying the obverse and reverse of a coin are fundamentally different things. I'm saying the coin has two faces. If you can show an asymmetric algorithm that's not convertible, I'd love to hear about it. No kidding, no sarcasm. >> This could only be true if everyone holds to a threat model in which >> their data being collected by the MDR and potentially decrypted by a >> First World nation-state actor is a risk that needs mitigation.? Most >> of us do not. > > The entire concept of dragnet mass-surveillance is that this is > *everyone?s* threat model. Bullshit it is. A couple of years ago I was at the Internet Freedom Festival in Valencia, Spain. I was in the break room when this massive bear of a Middle Eastern guy came up and asked in broken English if I was Rob from Enigmail. I said I was. This guy wrapped me in a hug that almost broke my ribs, lifted me off the ground, and thanked me for saving his life. I'm a large guy and this bear of a man was heaving me around like a sack of flour. He was a Syrian dissident and journalist who had used Enigmail to communicate securely with local Syrian sources and Western media contacts. al-Assad's regime threw him in jail. They worked him over but he didn't identify his contacts or decrypt his messages for the secret police, and a couple of weeks later international pressure led to his release. He left Syria for safety in Turkey. He bought me a beer and thanked me for my work with GnuPG and Enigmail, because we kept his contacts alive. (Me, I think this guys who spent *two weeks being tortured in a Syrian prison* is the real hero. But he was being very fulsome in sharing the credit.) My friend Ali Gharavi is a human rights volunteer who specializes in training people in how to communicate securely in hostile regimes. While visiting Turkey on an Amnesty International-funded trip to meet and train people from repressive Middle Eastern regimes, Tayyip Erdogan ordered him arrested on trumped-up charges. Ali was terrified his arrest would directly lead to compromised comms and Erdogan trading the names of dissidents for political favors from their home countries. That didn't come to pass, and after months of detention Ali got to go home. ( https://hivos.org/istanbul-10-released-hivos-very-relieved/ -- Ali is third from the left in the photo at the top. I do not know a kinder, more thoughtful gentleman.) These are two people I know, whom I've shared meals with, whom I've had tea with, for whom some enormous classified data repo in Utah was an extremely remote concern compared to their friends falling into the hands of an autocrat. Are you really telling me that they're wrong to say "nah, you know, RSA-3072 is fine for our purposes, but for God's sake, Rob, you have got to do *something* about Enigmail's usability in Farsi and Pashto"? Don't get me wrong. I'm entirely in favor of PQC and preparing for a transition. But you are revealing yourself to be a deeply unserious person, fond of making sweeping pronouncements without understanding of nuance. So far you have asserted: 1. Everyone needs to migrate to Kyber *now*. (No, we don't.) 2. There is a format war brewing between PGP specs. (There is not.) 3. It is imperative GnuPG win this format war. (Vacuously true by false premise.) 4. It is universally unethical to deploy encryption solutions or services that don't employ PQC, even if those solutions are vast improvements over plaintext. (No, it is not.) 5. Massive data repositories and dragnet surveillance by First World nation-states is part of everyone's threat model. (It is not.) After five claims, some of which were truly ludicrous, I'm done taking you seriously. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Sat Jan 4 03:18:06 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 3 Jan 2025 20:18:06 -0600 Subject: deflating heffalumps In-Reply-To: <9b0e67f4-fc1b-4a69-ab67-f287a9fbc95f@sixdemonbag.org> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> <5873f67f-9cd7-4266-b4fe-9ad74aab0c21@sixdemonbag.org> <5ac32cdf-caa6-4313-a34d-b0690b2ce14b@gmail.com> <9b0e67f4-fc1b-4a69-ab67-f287a9fbc95f@sixdemonbag.org> Message-ID: <7acf389a-7d03-4d36-9414-7ecdc66ad73f@gmail.com> On 1/2/25 22:59, Robert J. Hansen wrote: >> Do I understand correctly that, while the complexity of >> conventional factoring scales with a logarithm of RSA key length, >> Shor's algorithm has a space requirement that scales linearly, but >> the engineering challenges implied by that linear growth scale >> exponentially? > > The keyspace equivalency is made under the assumption the attacker is > using the generalized number field sieve. It's unsurprising for work > factors to be different for different algorithmic approaches. Your > conclusion is sound but please be careful not to draw inferences about > one approach from the behavior of the other. Yes, but you seem to be missing my intended point:? each additional RSA key bit far less than doubles the work to factor the key on a conventional computer, but nonetheless always add 5 additional qubits to the requirements for Shor's algorithm. "Only 5 more qubits" may not sound like much, but the difficulty of adding those compounds for each additional qubit. In theory, with long-enough (perhaps too long for practical use) RSA keys, conventional factoring would be /easier/ than Shor's algorithm.? Is there such a "turnover" point? One of the rationales for limiting GnuPG RSA keys to 4096 bits is those diminishing returns against GNFS factoring, but raising that limit may be appropriate to enable greater quantum resistance. (Lack of interoperability for longer RSA keys might be another good reason to keep the 4096-bit limit.) >> Are those figures including error correction or /before/ error >> correction? > > Before. So those figures are low by factor of ...?? (Somehow I suspect that quantum error correction is considerably less efficient than Reed-Solomon...) > [...] >> Do the mathematical complexities that prevent conventional >> computing from making short work of 256-bit ECC keys also affect >> Shor's algorithm? > > My understanding is "no". So a quantum computer able to solve RSA-256/384/512 can also solve EC-RSA-256/384/512 with the same difficulty? >> If not, that would mean that RSA is actually /stronger/ against >> future threats and TLS should be moving back to RSA and Diffie- >> Hellman posthaste. > The US government's belief is that RSA-3072 will be sufficient for > protection of Top Secret/SCI data for the next twenty-five years. > > [...] And what about the various elliptic curve cryptosystems? -- Jacob From rjh at sixdemonbag.org Sat Jan 4 04:51:32 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 3 Jan 2025 22:51:32 -0500 Subject: deflating heffalumps In-Reply-To: <7acf389a-7d03-4d36-9414-7ecdc66ad73f@gmail.com> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> <5873f67f-9cd7-4266-b4fe-9ad74aab0c21@sixdemonbag.org> <5ac32cdf-caa6-4313-a34d-b0690b2ce14b@gmail.com> <9b0e67f4-fc1b-4a69-ab67-f287a9fbc95f@sixdemonbag.org> <7acf389a-7d03-4d36-9414-7ecdc66ad73f@gmail.com> Message-ID: > In theory, with long-enough (perhaps too long for practical use) RSA > keys, conventional factoring would be /easier/ than Shor's algorithm. Is > there such a "turnover" point? When talking about science fiction technologies, the only answer is "who knows?" You'll hear me say that a lot here. If someone in the 1950s were to ask questions about computing technology today, the best minds of the '50s might be able to specify the physical limits of computing but none of them would have a clue as to how closely we'd approach those limits. Sure, there's probably a turnover point. Nobody has a clue where. Nobody thinks the GNFS is approaching the asymptotic limit of factoring: we just don't have a better algorithm. Yet. A number-theoretic breakthrough would move the turnover point enormously. So would engineering breakthroughs in coherence time. So would a proof of P=NP. So would... Who knows? The future does not come according to predictable progress. Stagnation and breakthrough is more often the case. My estimate of each computational qubit in a massive ensemble requiring five qubits of error correction is a wild guess that seems, according to my prejudices, pretty conservative. There's zero reason to take it as authoritative, consensus, or grounded in physical limits of the universe. > So those figures are low by factor of ...? Who knows? At present we can't build an ensemble even 1% the size needed to break RSA-4096. By the time we get to ensembles of that size, who knows what breakthroughs we'll also have made in quantum error correction? > So a quantum computer able to solve RSA-256/384/512 can also solve EC- > RSA-256/384/512 with the same difficulty? I answered this. >> The US government's belief is that RSA-3072 will be sufficient for >> protection of Top Secret/SCI data for the next twenty-five years. >> >> [...] > > And what about the various elliptic curve cryptosystems? I provided you with a link to the NSA's CNSA Suite 2.0. I did this hoping you would read it. Securing TS/SCI traffic with legacy CNSA 1.0 algorithms such as ECDH, ECDSA, and RSA will be officially approved until 2033 in most roles. After that, it's all PQC. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Sat Jan 4 20:00:19 2025 From: mm at dorfdsl.de (Marco Moock) Date: Sat, 4 Jan 2025 20:00:19 +0100 Subject: S/MIME which certificate format In-Reply-To: <87r07po0sr.fsf@jacob.g10code.de> References: <20240612213711.178b78da@dorfdsl.de> <87msnfn4at.fsf@jacob.g10code.de> <20241105131215.10b77ed1@ryz.dorfdsl.de> <875xp1q1xb.fsf@jacob.g10code.de> <20241105171135.6d3d4807@ryz.dorfdsl.de> <87r07po0sr.fsf@jacob.g10code.de> Message-ID: <20250104200019.65248212@ryz.dorfdsl.de> Am 05.11.2024 um 21:58:28 Uhr schrieb Werner Koch: > Thanks for the certificate; that is really helful. Please give me a > few days to check it. The good thing is that the parser works: > > $ ~/b/libksba/tests/cert-basic x.cer > Certificate in `x.cer': > serial....: (#00CDB882CF52A4258A4CB6FA03C415DDBD#) > issuer....: `CN=Sectigo RSA Client Authentication and Secure Email > CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB' > notBefore.: 2024-06-10 00:00:00 notAfter..: 2026-06-10 23:59:59 > hash algo.: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) > Extn: 2.5.29.35 (authorityKeyIdentifier) at 801 with length 24 > Extn: 2.5.29.14 (subjectKeyIdentifier) at 834 with length 22 > Extn: 2.5.29.15 (keyUsage) at 868 with length 4 (critical) > Extn: 2.5.29.19 (basicConstraints) at 884 with length 2 (critical) > Extn: 2.5.29.37 (extKeyUsage) at 895 with length 12 > Extn: 2.5.29.32 (certificatePolicies) at 916 with length 73 > Extn: 2.5.29.31 (cRLDistributionPoints) at 998 with length 83 > Extn: 1.3.6.1.5.5.7.1.1 (authorityInfoAccess) at 1096 with length 126 > Extn: 2.5.29.17 (subjectAltName) at 1234 with length 17 (critical) > SubjectKeyIdentifier: (#298E85EFE489A73582CC9324FDED349CDC915F33#) > AuthorityKeyIdentifier: > keyIdentifier: (#09C0F2FC0BDA94DB5FFE2BDFA89942CFC9E0AD00#) > KeyUsage: digitalSignature keyEncipherment > [...] > > Thus I only need to look at gpgsm code. Anything new regarding that? -- kind regards Marco From jcb62281 at gmail.com Sun Jan 5 03:52:39 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sat, 4 Jan 2025 20:52:39 -0600 Subject: deflating heffalumps In-Reply-To: References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <94465113-5745-4168-80f3-1a3f452f11a8@gmail.com> <5873f67f-9cd7-4266-b4fe-9ad74aab0c21@sixdemonbag.org> <5ac32cdf-caa6-4313-a34d-b0690b2ce14b@gmail.com> <9b0e67f4-fc1b-4a69-ab67-f287a9fbc95f@sixdemonbag.org> <7acf389a-7d03-4d36-9414-7ecdc66ad73f@gmail.com> Message-ID: <6eff60f6-d32d-46cc-9461-9ba83986b680@gmail.com> On 1/3/25 21:51, Robert J. Hansen wrote: > [...] > >> So a quantum computer able to solve RSA-256/384/512 can also solve >> EC- RSA-256/384/512 with the same difficulty? > > I answered this. I was checking my understanding, but see below. >>> The US government's belief is that RSA-3072 will be sufficient for >>> protection of Top Secret/SCI data for the next twenty-five years. >>> >>> [...] >> >> And what about the various elliptic curve cryptosystems? > > I provided you with a link to the NSA's CNSA Suite 2.0. I did this > hoping you would read it. > > Securing TS/SCI traffic with legacy CNSA 1.0 algorithms such as ECDH, > ECDSA, and RSA will be officially approved until 2033 in most roles. > After that, it's all PQC. So that means the US Government also expects the elliptic curve systems will be safe until at least 2058 (usable until 2033 plus 25 years to declassification).? Interesting. Thank you. -- Jacob From albrecht.dress at posteo.de Sun Jan 5 14:21:58 2025 From: albrecht.dress at posteo.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Sun, 05 Jan 2025 13:21:58 +0000 Subject: gpgsm unable to extract signers from a valid (?) signature In-Reply-To: <87bk03t1jr.fsf@jacob.g10code.de> Message-ID: Hi, first, a happy new year 2025 to everybody! Am 02.10.24 09:19 schrieb(en) Werner Koch: [snip] > Thus libksba does not see the actual signature but only the > certificates. The data is handled as a kind of certs-only message but > that's of course wrong. I'll get back to you as soon as I have had a > closer look at it. do you have any new findings re. this bug? A fix (in libksba?) would be highly appreciated! Thanks, Albrecht. -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Jan 6 09:09:28 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 Jan 2025 09:09:28 +0100 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> (have's message of "Fri, 3 Jan 2025 18:29:20 +0000") References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> Message-ID: <87msg4weh3.fsf_-_@jacob.g10code.de> Hi! On Fri, 3 Jan 2025 18:29, have--- said: > I won?t ambush a volunteer answering support@ for a free keyserver, > but I will publicly quote my own reply below. There has been no The concept of public keyservers is dead. It worked well in a past Internet with mostly friendly inhabitants. But we are not anymore in the 90ies and DoS is a major concern. There is also the false assumption of many users that keys from a keyserver are in any way trustworthy. There is one remaining reason for having a network of synced keyservers: To distribute revocations. Lookup of keys by anything other than a fingerprint has no more justification. And for that feature a simple distibuted storage for revocations would be better than the complex keyserver software we have today. For initail key discovering (lookup) there are better methods: - Send the key with your initial may and start to build up trust. (after all there must be some reason that you trust a mail address) - Send the key along with the initial signed message by using the gpg option --include-key-block. This does not even require mail. - Distribute the key along with your mail address using the Web Key directory. - For key discovery in a managed environment (large organization) use an LDAP keyserver. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From look at my.amazin.horse Mon Jan 6 10:53:43 2025 From: look at my.amazin.horse (Vincent Breitmoser) Date: Mon, 6 Jan 2025 10:53:43 +0100 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: <87msg4weh3.fsf_-_@jacob.g10code.de> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> Message-ID: Hey there, fair points here, for users who don't see value in certificate discovery via verifying keyservers. I would argue it's not universally agreed upon: We did see 60k newly verified email addresses on keys.openpgp.org in the last year though, adding to a total of half a million or so. > For initail key discovering (lookup) there are better methods: > > - Send the key with your initial may and start to build up trust. > (after all there must be some reason that you trust a mail address) > > - Send the key along with the initial signed message by using the gpg > option --include-key-block. This does not even require mail. > For both of these options, do you think PQC-sized public keys might become a challenge? Cheers - V From mcr+ietf at sandelman.ca Mon Jan 6 19:14:37 2025 From: mcr+ietf at sandelman.ca (Michael Richardson) Date: Mon, 06 Jan 2025 13:14:37 -0500 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: <87msg4weh3.fsf_-_@jacob.g10code.de> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> Message-ID: <20925.1736187277@obiwan.sandelman.ca> Werner Koch via Gnupg-users wrote: > There is one remaining reason for having a network of synced > keyservers: To distribute revocations. > Lookup of keys by anything other than a fingerprint has no more > justification. And for that feature a simple distibuted storage for > revocations would be better than the complex keyserver software we have > today. So if we mapped key IDs to convenient directory sized blocks, we could just use rsync? > - Distribute the key along with your mail address using the Web Key > directory. aren't there also proposals to do this via special mime types? -- Michael Richardson . o O ( IPv6 I?T consulting ) Sandelman Software Works Inc, Ottawa and Worldwide -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From steffen at sdaoden.eu Mon Jan 6 22:58:52 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 06 Jan 2025 22:58:52 +0100 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: <20925.1736187277@obiwan.sandelman.ca> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> <20925.1736187277@obiwan.sandelman.ca> Message-ID: <20250106215852.56Fjv16u@steffen%sdaoden.eu> [i removed have at anonymous.sex; never did such..] Michael Richardson wrote in <20925.1736187277 at obiwan.sandelman.ca>: |Werner Koch via Gnupg-users wrote: |> There is one remaining reason for having a network of synced |> keyservers: To distribute revocations. | |> Lookup of keys by anything other than a fingerprint has no more |> justification. And for that feature a simple distibuted storage for |> revocations would be better than the complex keyserver software we have |> today. | |So if we mapped key IDs to convenient directory sized blocks, we could just |use rsync? | |> - Distribute the key along with your mail address using the Web Key |> directory. | |aren't there also proposals to do this via special mime types? "Problem" is that .asc is not only used for key distribution, but also for normal signatures. Iirc this at least bites the original intent. I should reread all of PKI etc. A combination of DKIM and special email addresses which send emails which are signed and include the public key so that the email can be used to verify itself also seems a cryptographically verifiable thing (if it is). And if only ever DNSSEC would be supported by the giants... (I still cannot believe that these post quantum things will all be so terribly huge data things.) --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) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear From have at anonymous.sex Tue Jan 7 05:09:52 2025 From: have at anonymous.sex (have at anonymous.sex) Date: Tue, 7 Jan 2025 04:09:52 +0000 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: <87msg4weh3.fsf_-_@jacob.g10code.de> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> Message-ID: On Mon, 06 Jan 2025 09:09:28 +0100, Werner Koch wrote (quotes rearranged): >For initail key discovering (lookup) there are better methods: Thanks for the tips. >- Send the key with your initial may and start to build up trust. >(after all there must be some reason that you trust a mail address) A question of netiquette: Is it acceptable to do this on a first post to a public list? To the end stated in OP, I have taken the liberty of hereby attaching a LibrePGP key with hybrid post-quantum encryption subkey and with the OCB feature flag enabled. But I would not ordinarily send a key to a list?not even once (and especially not when FIPS 205/SPHINCS+ with its large signatures is implemented and used for long-term identity certification [C] keys). It was my primary motive for attempting the keyserver. When cold-contacting a stranger, I habitually attach one or more PGP keys as MIME type application/pgp-keys. Users of some mail clients may need to be cautious about a wrong MIME type. >-[...more suggestions...] > >- Distribute the key along with your mail address using the Web Key >directory. What is the best practice for using WKD to distribute multiple keys for the same mail address, potentially with different PGP version bytes (v4/v5) during a time when early adopters of a new version want to continue supporting an obsolete version for awhile? In preparation maybe to set up a WWW site, I?ve been intending to write a separate thread about that... here goes: ??3.1 of WKD (draft 19) states that a keyserver ?may? return a revoked key and a new key in a single request as ?concatenated key blocks?. However, it does not address the cases of: * Multiple valid keys. * WKD client acceptance of a key in a recognized version, when it is concatenated (prepended or appended) with a key is in an unrecognized version. (It is presumed here that the packet formats are the same ?New Format Packet? as defined in RFC4880/LibrePGP ??4.2; otherwise, it looks like binary garbage and packet lengths cannot be parsed.) * Prioritization of keys. Prefer first? Last? Highest version? Best crypto? As a practical matter, in-the-wild client behavior needs to be tested. It?s a nontrivial problem; one of the major WKD clients is a ?web app? which cannot be installed and scripted in a controlled test environment without an account on a remote server. GnuPG?s behavior should also be tested by concatenating a v4/v5 key with a key in a nonexistent packet version, say v255. If I take this up sometime, I will post to -devel. I hope that I can find some automagical way for WKD to make all correspondents use the best key for me that they support, until I fully deprecate v4 keys. Not-quite-OT: >The concept of public keyservers is dead. It worked well in a past >Internet with mostly friendly inhabitants. But we are not anymore in >the 90ies and DoS is a major concern. There is also the false >assumption of many users that keys from a keyserver are in any way >trustworthy. And we are not anymore in the 90ies when the zeroth rule of security was not to run network-loaded executable code, most tech-savvy people disabled javascript and java in their WWW browsers (duh), people did not hide their mail addresses (good), mailservers accepted mail from friendly strangers without a stupid robot passing judgment on whether it should be silently junked (good), nobody except plan9 had proper UTF-8 support (bad), timestamps were absolute and not relative time (good), SSL was only for shopping (bad), PGP users blithely documented their social graphs via Web of Trust (bad; thanks for GnuPG?s TOFU mode), the future author of NaCl had also not yet invented the term ?post-quantum crypto? :-(, and people cared enough to have RSA tattoos and blue ribbons and such. Did you know that early Hotmail worked in Lynx? (Without PGP, of necessity for a few months when I was young and had limited options for Net access.) Their frameset was tricky to navigate in Lynx, but it did work. Not to put too fine a point on it, but I think getting more in-the-wild user PQ keys for the first major \*PGP implementation with usable PQ encryption would be consistent with the spirit of the Net. GnuPG 2.5.1 30 days after NIST final FIPS-203 = write code, protect users. -- # Remember these on Wednesday, January 15, 2025: https://web.archive.org/web/19971024171609/http://www.eff.org/blueribbon.html https://web.archive.org/web/19971114041230/http://www.eff.org/pub/Legal/Cases/ACLU_v_Reno/19970626_eff_cda.announce https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/23-1122.html -------------- next part -------------- A non-text attachment was scrubbed... Name: have-post-quantum-anonymous-sex.asc Type: application/pgp-keys Size: 3106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 297 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue Jan 7 06:32:36 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 7 Jan 2025 00:32:36 -0500 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> Message-ID: > A question of netiquette:? Is it acceptable to do this on a first post > to a public list? IIRC, Autocrypt specifies a way for public keys to be transferred in an email header that's parsed by Autocrypt-aware clients and not rendered or acted upon by non-aware clients. Seems like the best thing going right now. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From have at anonymous.sex Tue Jan 7 07:49:11 2025 From: have at anonymous.sex (have at anonymous.sex) Date: Tue, 7 Jan 2025 06:49:11 +0000 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: <20250106215852.56Fjv16u@steffen%sdaoden.eu> References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> <20925.1736187277@obiwan.sandelman.ca> <20250106215852.56Fjv16u@steffen%sdaoden.eu> Message-ID: <97d429b6-cf45-9b52-a25c-5e3f0d753214@anonymous.sex> On Mon, 06 Jan 2025 22:58:52 +0100, Steffen Nurpmeso wrote: >>>- Distribute the key along with your mail address using the Web Key >>>directory. > >>aren't there also proposals to do this via special mime types? > >"Problem" is that .asc is not only used for key distribution, but also >for normal signatures. Iirc this at least bites the original intent. File ?extension? means nothing here. Web Key Directory (WKD) is this; it does not have any file extension: https://wiki.gnupg.org/WKD https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ The proper MIME type for WKD is application/octet-stream, according to ??3.1 of WKD (draft 19) linked above. **Important:** When you attach your key to mail, use the MIME type application/pgp-keys. Consult your mail client?s manual for instructions. It shouldn?t matter what the filename is; if the filename is ?iloveyou.doc.exe? and the MIME type is application/pgp-keys, a proper receiving mail client will see it as a PGP key. >A combination of DKIM and special email addresses which send emails >which are signed and include the public key so that the email can be >used to verify itself also seems a cryptographically verifiable thing >(if it is). No, it?s not. Please study cryptography before attempting protocol design. >(I still cannot believe that these post quantum things will all be so >terribly huge data things.) I attached a post-quantum thing to my prior list message, and it is downloadable from the list server; observe the size and the correct MIME type: https://lists.gnupg.org/pipermail/gnupg-users/2025-January/067460.html >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: have-post-quantum-anonymous-sex.asc >Type: application/pgp-keys >Size: 3106 bytes >Desc: not available >URL: Fingerprint: 01A6D 81EEA D7EEE C393D EC140 1F489 4C154 E1B8E E32E9 059CA That 3106 bytes is the ASCII-armored version of a blob with an ed448 primary certification and signing key (non-PQ), a ky1024_cv448 subkey (PQ), one simple userid, and one trust signature from my ed25519 (v4) key. Requires GnuPG 2.5.1 or later. >[i removed have at anonymous.sex; never did such..] Rude. Shame on you. -- # Remember these on Wednesday, January 15, 2025: https://web.archive.org/web/19971024171609/http://www.eff.org/blueribbon.html https://web.archive.org/web/19971114041230/http://www.eff.org/pub/Legal/Cases/ACLU_v_Reno/19970626_eff_cda.announce https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/23-1122.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 297 bytes Desc: not available URL: From have at anonymous.sex Tue Jan 7 07:34:02 2025 From: have at anonymous.sex (have at anonymous.sex) Date: Tue, 7 Jan 2025 06:34:02 +0000 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> Message-ID: <32cb8ad5-46d7-9554-8752-15cc406b8f55@anonymous.sex> On Mon, 6 Jan 2025 10:53:43 +0100, Vincent Breitmoser wrote: >...do you think PQC-sized public keys might become a challenge? I attached to my prior list message the same PQC key that was rejected by keys.openpgp.org when I tried to upload it. It?s 3106 bytes, ASCII-armored. PQ keys with SPHINCS+ signatures (SLH-DSA, FIPS-205) will obviously be much bigger, not to mention PQ keys with a Classic McEliece encryption subkey if we could please get that wired in from the libgcrypt support added last year. (Pretty please?) I know that *you* know the difference between that and a little lettuce ?,[0] but other -users members may not. I?ve been trying to figure out some hackish workarounds for the potential sizes of such keys. It?s off-topic for -users, and not ready yet; anyone who is interested now may contact me off-list, preferably using PQ-PGP. [0] Apologies to non-English speakers. I stole the lettuce/lattice joke from some cryptography talk I saw somewhere, where the presenter made the same apology. -- # Remember these on Wednesday, January 15, 2025: https://web.archive.org/web/19971024171609/http://www.eff.org/blueribbon.html https://web.archive.org/web/19971114041230/http://www.eff.org/pub/Legal/Cases/ACLU_v_Reno/19970626_eff_cda.announce https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/23-1122.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 297 bytes Desc: not available URL: From wk at gnupg.org Tue Jan 7 09:12:23 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Jan 2025 09:12:23 +0100 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: <20925.1736187277@obiwan.sandelman.ca> (Michael Richardson's message of "Mon, 06 Jan 2025 13:14:37 -0500") References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> <20925.1736187277@obiwan.sandelman.ca> Message-ID: <87zfk3ujo8.fsf@jacob.g10code.de> On Mon, 6 Jan 2025 13:14, Michael Richardson said: > > - Distribute the key along with your mail address using the Web Key > > directory. > > aren't there also proposals to do this via special mime types? Sure, but that is a different thing. application/gpg-keys is a long established content type. However it only works with full PGP/MIME aware MUAs. It does not work if you exchange encrypted/signed files by other means. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From have at anonymous.sex Tue Jan 7 09:49:30 2025 From: have at anonymous.sex (have at anonymous.sex) Date: Tue, 7 Jan 2025 08:49:30 +0000 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> Message-ID: <96276a53-5c81-9654-9cc3-cc33ab99f5a3@anonymous.sex> On Tue, 7 Jan 2025 00:32:36 -0500, Robert J. Hansen wrote: >IIRC, Autocrypt specifies a way for public keys to be transferred in >an email header that's parsed by Autocrypt-aware clients and not >rendered or acted upon by non-aware clients. Seems like the best thing >going right now. Thanks for the suggestion. I see your headers. The last time that I tried to get Autocrypt working, it failed due to my unusual local configuration (probably not an Autocrypt issue). I should try again. In the interim, I placed some new headers in my mail to give people (a) alleged fingerprints, (b) an alleged last-modified hint to help clients keep it refreshed, (c) a pointer to my key (albeit not here one I can update), and (d) a brief advocacy message for humans. I dislike the abbreviation that I used, but I wanted to make my v5 fingerprint fit on one line in a standard 80-column terminal. Perhaps there should be a standard for such header lines, which MUAs can automagically parse and use without inclusion of the full key in the header of every message. Perhaps there already is, and I don?t know? **Note to users who trust too much:** These header lines are unauthenticated, and MUST NOT be treated as verified information. My intended threat model here is like Autocrypt. -- # Remember these on Wednesday, January 15, 2025: https://web.archive.org/web/19971024171609/http://www.eff.org/blueribbon.html https://web.archive.org/web/19971114041230/http://www.eff.org/pub/Legal/Cases/ACLU_v_Reno/19970626_eff_cda.announce https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/23-1122.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 297 bytes Desc: not available URL: From fg.gnupg at shimps.de Tue Jan 7 15:40:12 2025 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Tue, 7 Jan 2025 15:40:12 +0100 Subject: Infrastructure support for GnuPG post-quantum keys In-Reply-To: References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> <6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex> <87msg4weh3.fsf_-_@jacob.g10code.de> Message-ID: <20250107154012.24aee9b0@incubator.example.net> On Tue, 7 Jan 2025 04:09:52 +0000 have--- via Gnupg-users wrote: > > A question of netiquette: Is it acceptable to do this on a first > post to a public list? Without having a final answer, some thoughts: 1. Signed emails which are sent to a list can be verified only with the public key. Thus the other list members should have a chance to get this key. 2. Sending the key once will exclude those people / list members who join afterwards. 3. Sending the key always will increase traffic and amount of used storage space. Maybe this isn't any kind of real issue nowadays. 4. Given a public mailing list archive, can the key be extracted from there in the far future? Which format would be suitable for this? Are the headers archived completely? 5. The WKD web key directory looks like a suitable workflow to distribute public keys without repeated overhead inside the emails itselves. Just as a proof of concept for myself, I tried it several months ago. It's easy to setup in conjunction with some webspace. Actually this is only a "works for me" solution, YMMV. I do not claim it to be _the_ single and universal solution. 6. Maybe the final answer is not agreeing on a single distribution workflow but having different options live and in the wild. This could protect against suprising disruption attacks against the ecosystem as it happended with keyservers in the past. -- kind regards Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From fg.gnupg at shimps.de Fri Jan 10 13:00:34 2025 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Fri, 10 Jan 2025 13:00:34 +0100 Subject: External Debian apt repository In-Reply-To: <20241217170042.742643b7@incubator.example.net> References: <20241217170042.742643b7@incubator.example.net> Message-ID: <20250110130034.47b3e0da@incubator.example.net> On Tue, 17 Dec 2024 17:00:42 +0100 Frank Guthausen wrote: > > shimps-gnupg-ng - GnuPG 2.5.2 shipping speedo compiled binaries only > in /opt/local/shimps (32M) including libraries Updated to GnuPG 2.5.3 (released yesterday 2025-01-09) from the ``GnuPG (devel with libs)'' sources. -- kind regards Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Sun Jan 12 15:10:06 2025 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 12 Jan 2025 15:10:06 +0100 Subject: Betamax v. VHS, and the future of PQ-PGP In-Reply-To: References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex> Message-ID: <8dc0a7b7-18c9-5bc2-04d0-0ce702fc3a1d@vulcan.xs4all.nl> On 2025-01-03 1:25, Robert J. Hansen via Gnupg-users wrote: > Let me get this straight: you believe Signal is acting unethically and > irresponsibly by giving people a superb and secure alternative to SMS > messaging, just because they don't support PQC. Actually Signal uses PQC for some time now. They stage it with conventional crypto to be on the safe side if one of them gets broken. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From eric.pruitt at gmail.com Mon Jan 13 07:12:24 2025 From: eric.pruitt at gmail.com (Eric Pruitt) Date: Sun, 12 Jan 2025 22:12:24 -0800 Subject: Echo password when using TTY Message-ID: Is it possible to get GPG to enable echoing input when prompting the user for a password? Since symmetric encryption prompts the user for a password once, it's vulnerable to silent typos, so I find myself decrypting files to double check the password when I generally wouldn't have to do this if I could see what I typed. Eric From wk at gnupg.org Tue Jan 14 10:54:55 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 14 Jan 2025 10:54:55 +0100 Subject: [Announce] GnuPG 2.5.3 released Message-ID: <87msftsosw.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.3. This release is the fourth of a series of public testing releases eventually leading to a new stable version 2.6. We also release a second Beta version of the forthcoming Gpg4win 5.0. The main features in the 2.6 series are improvements for 64 bit Windows and the introduction of a PQC encryption algorithm. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.5.3 (2025-01-09) ================================================ [compared to version 2.5.2] * gpg: Allow for signature subpackets of up to 30000 octets. [rG36dbca3e69] * gpg: Silence expired trusted-key diagnostics in quiet mode. [T7351] * gpg: Allow smaller session keys with Kyber and enforce the use of AES-256 if useful. [T7472] * gpg: Fix regression in key generation from existing card key. [T7309,T7457] * gpg: Print a warning if the card backup key could not be written. [T2169] * The --supervised options of gpg-agent and dirmngr have been renamed to --deprecated-supervised as preparation for their removal. [rGa019a0fcd8] * There is no more default for a keyserver. Release-info: https://dev.gnupg.org/T7442 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary file server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.3.tar.bz2 (7989k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.3.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.3_20250109.exe (5655k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.3_20250109.exe.sig The source used to build this installer for 64-bit Windows is available at https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.3_20250109.tar.xz (16M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.3_20250109.tar.xz.sig This Windows source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README. For Windows a *Beta* version of Gpg4win, our full featured Gpg4win installer including this version of GnuPG as well as Kleopatra GUI and a PDF editor can be retrieved from here: https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta51/gpg4win-5.0.0-beta51.exe (43M) https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta51/gpg4win-5.0.0-beta51.exe.sig with the source code at: https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta51/gpg4win-5.0.0-beta51.tar.xz (279M) https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta51/gpg4win-5.0.0-beta51.tar.xz.sig Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.5.3.tar.bz2 you would use this command: gpg --verify gnupg-2.5.3.tar.bz2.sig gnupg-2.5.3.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.5.3.tar.bz2, you run the command like this: sha1sum gnupg-2.5.3.tar.bz2 and check that the output matches the next line: 6dd8c940e1dff21d5e333a0ad3066e269e83df5e gnupg-2.5.3.tar.bz2 50f416d52eb423e5b359812ba02ceca2cea85c91 gnupg-w32-2.5.3_20250109.tar.xz acb39daee05aced0d37195f4ad739c16bda9aa5e gnupg-w32-2.5.3_20250109.exe 84a1169f55e3ddef02567fd0f3a0b666a9881107 gpg4win-5.0.0-beta51.exe 2fa55c64ed9238c7b745fa8d54978d4713a7e2b9 gpg4win-5.0.0-beta51.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T7442 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. 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. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 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 mr-manuel at outlook.it Tue Jan 14 16:32:25 2025 From: mr-manuel at outlook.it (Mr. Manuel) Date: Tue, 14 Jan 2025 15:32:25 +0000 Subject: Forum registration Message-ID: Hello, unfortunately, the forum registration is currently disabled. Would it be possible to get a user in the forum (https://dev.gnupg.org)? "mr-manuel", "Manuel", "mr-manuel at outlook.it" Thanks! Regards, Manuel From mr-manuel at outlook.it Tue Jan 14 16:08:06 2025 From: mr-manuel at outlook.it (Mr. Manuel) Date: Tue, 14 Jan 2025 15:08:06 +0000 Subject: Forum registration Message-ID: Hello, unfortunately, the forum registration is currently disabled. Would it be possible to get a user in the forum (https://dev.gnupg.org)? "mr-manuel", "Manuel", "mr-manuel at outlook.it" Thanks! Regards, Manuel From mcdonald_seth at pm.me Fri Jan 17 23:59:51 2025 From: mcdonald_seth at pm.me (Seth McDonald) Date: Fri, 17 Jan 2025 22:59:51 +0000 Subject: Design of a Modern Keyserver Network Message-ID: Hello all, For about the past month or two, I've been researching and teaching myself OpenPGP and GnuPG, which led to me attempting to find out what happened to all the keyservers over the past few years, since many resources on GnuPG reference keyservers which no longer function. To my understanding, it seems the vast majority of keyservers (connected via the 'SKS network') were functionally damaged due to a 2019 'certificate poisoning' attack, and were subsequently shut down in 2021 due to being unable to comply with the GDPR. As such, I decided to take a crack at rectifying the design of the keyserver network. I've written a detailed outline in a GitHub Gist, which I'll link below. But to give a brief summary, I break down the requirements of a modern keyserver network into six main criteria, including the storage and distribution of public keys, the ability to defend against state force, the ability to withstand the previously inflicted attacks, etc. And to meet these criteria, I propose the use of metadata in the storage and distribution of public keys. In particular, every public key can carry with it three pieces of metadata: a hash, a detached signature, and a revocation certificate. The hash is unique to a key upload attempt and the signature is of the hash, generated in the process of uploading the public key to confirm the client has access to the private key. The signature is checked to be valid both when uploading and synchronising the public key. The revocation certificate is given when first uploading the public key, and if added to the public key itself, will tell the keyserver to remove most data pertaining to that key. https://gist.github.com/McDaMastR/d4781ce0fd0e4a0ad60fd85201031f5d I would be beyond grateful if you could provide some constructive feedback! Sincerely, Seth. PGP Fingerprint 82B9 620E 53D0 A1AE 2D69 6111 C267 B002 0A90 0289 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 343 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Sat Jan 18 15:11:29 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 18 Jan 2025 14:11:29 +0000 Subject: Design of a Modern Keyserver Network In-Reply-To: References: Message-ID: <60719CA9-5AD4-45F8-A03A-06AEAFDFAFD0@andrewg.com> Hi, Seth. On 17 Jan 2025, at 22:59, Seth McDonald via Gnupg-users wrote: > > To my understanding, it seems the vast > majority of keyservers (connected via the 'SKS network') were functionally > damaged due to a 2019 'certificate poisoning' attack, and were subsequently > shut down in 2021 due to being unable to comply with the GDPR. This is not strictly accurate. The sks-keyservers.net domain shut down due to the legal ambiguity of running (effectively) a proxy service for random other operators. And the SKS network transitioned away from the sks-keyserver software (which was unable to handle deletion requests or poisoned keys) to the more modern hockeypuck software (see https://hockeypuck.io ). In the meantime, keys.openpgp.org was set up as a less-functional (but more reliable) service that was suitable as a safe default for existing clients. The SKS network is therefore alive and well, it just doesn?t run on sks-keyserver any more. It also has fewer nodes (currently 21 exposed publicly) than it did at its peak (over 100) -- but due to the more modern codebase it is much more performant (and reliable). You can see the current state of the network at https://spider.pgpkeys.eu It is a long-term goal of most operators to realign the various keyservers around a more sustainable model. Suggestions are always appreciated, and anyone interested in working on keyserver improvements is most welcome. :-) > https://gist.github.com/McDaMastR/d4781ce0fd0e4a0ad60fd85201031f5d > > I would be beyond grateful if you could provide some constructive feedback! Thanks for this; I?ll read through it in more detail later. You may also be interested in the various existing proposals for fixing keyservers, some of which are already in the process of being implemented: * https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-1pa3pc * https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore/ * https://github.com/hockeypuck/hockeypuck/wiki/HIP-3:-Timestamp-aware-merge-strategy * https://github.com/hockeypuck/hockeypuck/wiki/HIP-5:-Reliable-personal-data-deletion-using-self-signatures Thanks again for your interest in the keyservers! A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From doug.hs at proton.me Sun Jan 19 18:30:16 2025 From: doug.hs at proton.me (Douglas Silva) Date: Sun, 19 Jan 2025 17:30:16 +0000 Subject: dev.gnupg.org user registration Message-ID: I'd like an account at dev.gnupg.org. dsilva Douglas Silva doug.hs at proton.me Thank you. From mcr at sandelman.ca Mon Jan 20 23:48:06 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 20 Jan 2025 17:48:06 -0500 Subject: Design of a Modern Keyserver Network In-Reply-To: References: Message-ID: <20345.1737413286@obiwan.sandelman.ca> Thank you for this post. It's not particularly GNUPG specific, maybe this belongs on openpgp at ietf.org. Maybe your gist should become an Internet-Draft. Re Steps 3,4,5: * The keyserver sends the resultant hash to Alice via email using the email address given on her public key's UID. * Alice receives the hash, signs it using her private key, and inputs and submits the ASCII-armoured detached signature to the website, sending it to the keyserver. * The keyserver verifies the signature, and if it is indeed valid, Alice's public key is successfully uploaded. This sounds to my ears a bit like autocrypt. Could it be? As for revocation, and the server(s) having access to it. 1. does Alice have to interact with the same server? (I think so?) Does she even remember which one? :-) 2. it seems that a compromise of a keyserver system could allow attackers to push revocation certificates out for anyone/everyone. I agree with removing photo-like extensions from the key to reduce mischief. I wonder if removing the UID information from a key is enough to be forgotten (vs the entire key). The three responsabilities you list seem to rest upon the key servers always having revocation certificates available, and this concerns me for the reason above. Other than this concern, I think your design is right on. I can't think of a way to satisfy requirements 4,5,6 without the revocation certificiates available, and I think this might be the achilles heel here. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 511 bytes Desc: not available URL: From guru at unixarea.de Wed Jan 22 11:32:00 2025 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 22 Jan 2025 11:32:00 +0100 Subject: Fwd: VHV =?utf-8?Q?=E2=80=93_Automatische_?= =?utf-8?Q?Eingangsbest=C3=A4tigung?= Message-ID: Hello, I asked an Insurance Company in its web pages for contacting me and got the two attachments without any further text in the body of the mail. What can or should I do to read the encrypted text? Thanks matthias ----- Forwarded message from VHV Versicherungen ----- Date: Wed, 22 Jan 2025 10:55:58 +0100 From: VHV Versicherungen To: "guru at unixarea.de" Subject: VHV ? Automatische Eingangsbest?tigung ----- End forwarded message ----- -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023) I, Matthias, I am not at war with Russia. ? ?? ???? ? ???????. Ich bin nicht im Krieg mit Russland. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-encrypted Size: 11 bytes Desc: PGP/MIME version identification URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: encrypted.asc Type: application/octet-stream Size: 1998 bytes Desc: OpenPGP encrypted message URL: From mm at dorfdsl.de Wed Jan 22 15:03:27 2025 From: mm at dorfdsl.de (Marco Moock) Date: Wed, 22 Jan 2025 15:03:27 +0100 Subject: VHV =?UTF-8?B?4oCT?= Automatische =?UTF-8?B?RWluZ2FuZ3NiZXN0?= =?UTF-8?B?w6R0aWd1bmc=?= In-Reply-To: References: Message-ID: <20250122150327.4e5e2483@zbook> Am Wed, 22 Jan 2025 11:32:00 +0100 schrieb Matthias Apitz : > I asked an Insurance Company in its web pages for contacting me > and got the two attachments without any further text in the body of > the mail. What can or should I do to read the encrypted text? Do you have GPG set up and a keypair? From m.mansfeld at mansfeld-elektronik.de Wed Jan 22 14:51:29 2025 From: m.mansfeld at mansfeld-elektronik.de (Mansfeld Elektronik) Date: Wed, 22 Jan 2025 14:51:29 +0100 Subject: =?UTF-8?Q?Re=3A_Fwd=3A_VHV_=E2=80=93_Automatische_Eingangsbest?= =?UTF-8?Q?=C3=A4tigung?= In-Reply-To: References: Message-ID: <4e1ed8b2bf788e0ab6c22b0ca7a5cf2a@mansfeld-elektronik.de> The only idea is, they have something which looks automatically for sender's pubkeys on keyservers oder anywhere else, no matter if useful/valid/expired or not and then encrypts against these keys. In the best case you should be able to decrypt this *.asc attachment with one of your keys? IIRC I had a similar scenario some years ago, don't remember whether this was an insurance company or a telecom provider or something else..... IIRC they encrypted anything, not just autoreplies, against the first best fitting pubkey they found on keyservers. I don't remember whether I could decrypt that stuff or not.... Regards also Matthias :-) Am 22.01.2025 11:32, schrieb Matthias Apitz: > Hello, > > I asked an Insurance Company in its web pages for contacting me > and got the two attachments without any further text in the body of the > mail. What can or should I do to read the encrypted text? > > Thanks > > matthias > > ----- Forwarded message from VHV Versicherungen ----- > > Date: Wed, 22 Jan 2025 10:55:58 +0100 > From: VHV Versicherungen > To: "guru at unixarea.de" > Subject: VHV ? Automatische Eingangsbest?tigung > > > ----- End forwarded message ----- > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users -- Unsere Korrespondenz kann mitgelesen werden. Wollen Sie das erschweren, mailen wir uns gerne mit (Open)PGP verschl?sselt. - Matthias Mansfeld Elektronik * Leiterplattenlayout Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8 Internet: http://www.mansfeld-elektronik.de OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From guru at unixarea.de Wed Jan 22 16:33:23 2025 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 22 Jan 2025 16:33:23 +0100 Subject: VHV =?utf-8?Q?=E2=80=93_Automatische_E?= =?utf-8?Q?ingangsbest=C3=A4tigung?= In-Reply-To: <20250122150327.4e5e2483@zbook> References: <20250122150327.4e5e2483@zbook> Message-ID: El d?a mi?rcoles, enero 22, 2025 a las 03:03:27 +0100, Marco Moock escribi?: > Am Wed, 22 Jan 2025 11:32:00 +0100 > schrieb Matthias Apitz : > > > I asked an Insurance Company in its web pages for contacting me > > and got the two attachments without any further text in the body of > > the mail. What can or should I do to read the encrypted text? > > Do you have GPG set up and a keypair? Ofc, I have: purism at pureos:~$ touch foo purism at pureos:~$ gpg -ea foo You did not specify a user ID. (you may use "-r") Current recipients: Enter the user ID. End with an empty line: guru Current recipients: rsa4096/029AE568981CBAF1 2024-05-12 "Matthias Apitz (OpenPGP card 2) " Enter the user ID. End with an empty line: purism at pureos:~$ ls -l foo* -rw-r--r-- 1 purism purism 0 Jan 22 16:08 foo -rw-r--r-- 1 purism purism 862 Jan 22 16:08 foo.asc purism at pureos:~$ gpg -d foo.asc gpg: encrypted with 4096-bit RSA key, ID 029AE568981CBAF1, created 2024-05-12 "Matthias Apitz (OpenPGP card 2) " purism at pureos:~$ but its pub key is not in the wild. May be they used some old or something wrong. -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023) I, Matthias, I am not at war with Russia. ? ?? ???? ? ???????. Ich bin nicht im Krieg mit Russland. From andrewg at andrewg.com Wed Jan 22 16:39:24 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 22 Jan 2025 15:39:24 +0000 Subject: =?utf-8?Q?Re=3A_VHV_=E2=80=93_Automatische_Eingangsbest=C3=A4tigu?= =?utf-8?Q?ng?= In-Reply-To: References: <20250122150327.4e5e2483@zbook> Message-ID: <3AEF5D91-9322-4C1F-86A8-ECE64DB5C8B3@andrewg.com> On 22 Jan 2025, at 15:33, Matthias Apitz wrote: > > El d?a mi?rcoles, enero 22, 2025 a las 03:03:27 +0100, Marco Moock escribi?: > >> Do you have GPG set up and a keypair? > > Ofc, I have: > > > purism at pureos:~$ touch foo > purism at pureos:~$ gpg -ea foo > You did not specify a user ID. (you may use "-r") > > Current recipients: > > Enter the user ID. End with an empty line: guru > > Current recipients: > rsa4096/029AE568981CBAF1 2024-05-12 "Matthias Apitz (OpenPGP card 2) >" > > Enter the user ID. End with an empty line: > purism at pureos:~$ ls -l foo* > -rw-r--r-- 1 purism purism 0 Jan 22 16:08 foo > -rw-r--r-- 1 purism purism 862 Jan 22 16:08 foo.asc > purism at pureos:~$ gpg -d foo.asc > gpg: encrypted with 4096-bit RSA key, ID 029AE568981CBAF1, created 2024-05-12 > "Matthias Apitz (OpenPGP card 2) >" > purism at pureos:~$ > > but its pub key is not in the wild. > May be they used some old or something wrong. This is the key they encrypted the message to: https://pgpkeys.eu/pks/lookup?search=0x25C9A6C3&fingerprint=on&op=index A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Wed Jan 22 17:07:04 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Jan 2025 17:07:04 +0100 Subject: Fwd: VHV =?utf-8?Q?=E2=80=93?= Automatische =?utf-8?Q?Eingang?= =?utf-8?Q?sbest=C3=A4tigung?= In-Reply-To: (Matthias Apitz's message of "Wed, 22 Jan 2025 11:32:00 +0100") References: Message-ID: <87wmemoms7.fsf@jacob.g10code.de> Hi Matthias, On Wed, 22 Jan 2025 11:32, Matthias Apitz said: > and got the two attachments without any further text in the body of the > mail. What can or should I do to read the encrypted text? That is a common behaviour of gateways. The mail is decrypted to you. If you have a not too old version of Kleopatra you could simple open the second file with Kleopatra and read it with its integrated mime viewer. Or just decrypt and parse the MIME stuff with other tools or your eyes (in case they exceptionally didn't base64 encode all mails). Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From guru at unixarea.de Wed Jan 22 18:09:31 2025 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 22 Jan 2025 18:09:31 +0100 Subject: VHV =?utf-8?Q?=E2=80=93_Automatische_E?= =?utf-8?Q?ingangsbest=C3=A4tigung?= In-Reply-To: <3AEF5D91-9322-4C1F-86A8-ECE64DB5C8B3@andrewg.com> References: <20250122150327.4e5e2483@zbook> <3AEF5D91-9322-4C1F-86A8-ECE64DB5C8B3@andrewg.com> Message-ID: El d?a mi?rcoles, enero 22, 2025 a las 03:39:24p. m. +0000, Andrew Gallagher escribi?: > This is the key they encrypted the message to: > > https://pgpkeys.eu/pks/lookup?search=0x25C9A6C3&fingerprint=on&op=index > > A Yeah, this is the OpenPGP-card key of the card in my USB-dongle for my laptop (which I seldom use because I have the same password-store in my Linux in my Linux-cellphone with another OpenPGP-card). Don't know how they got its public key. In the laptop the message decrypts fine. Thanks for your help. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023) I, Matthias, I am not at war with Russia. ? ?? ???? ? ???????. Ich bin nicht im Krieg mit Russland. From mcdonald_seth at pm.me Mon Jan 27 08:57:24 2025 From: mcdonald_seth at pm.me (Seth McDonald) Date: Mon, 27 Jan 2025 07:57:24 +0000 Subject: Design of a Modern Keyserver Network In-Reply-To: <20345.1737413286@obiwan.sandelman.ca> References: <20345.1737413286@obiwan.sandelman.ca> Message-ID: > Thank you for this post. > It's not particularly GNUPG specific, maybe this belongs on openpgp at ietf.org. Thanks, I'll give it a look! > Re Steps 3,4,5: > > * The keyserver sends the resultant hash to Alice via email using the email address given on her public key's UID. > * Alice receives the hash, signs it using her private key, and inputs and submits the ASCII-armoured detached signature to the website, sending it to the keyserver. > * The keyserver verifies the signature, and if it is indeed valid, Alice's public key is successfully uploaded. > > This sounds to my ears a bit like autocrypt. > Could it be? To my understanding, Autocrypt is a specification which details how emails should include a particular header containing the sender's public key, allowing for automated key exchange and subsequent encryption. However, the steps in question aim to verify that the client (Alice) has 1) access to the email address, and 2) access to the private key. This is done by including in the body of the email some data (in this case a hash), and requiring the client to sign that data with the private key. So I suppose it's similar in the sense that communication occurs via email, though the purpose of this communication is much different. > As for revocation, and the server(s) having access to it. > 1. does Alice have to interact with the same server? (I think so?) > Does she even remember which one? :-) Given that the revocation certificates are stored in the metadata of the public keys, they should just be synchronised across keyservers along with the rest of the keys, allowing revocation to occur at any keyserver in the synchronising network. > 2. it seems that a compromise of a keyserver system could allow attackers to > push revocation certificates out for anyone/everyone. Indeed, this is a weakness of the design. However, it also means that of the possible attacks against a keyserver network, the least infeasible against this design is not certificate poisoning, but rather unwanted revocation. And while such an attack would certainly be disruptive and annoying, it can be rectified with relative ease: just generate a new key pair and upload the new public key. Users of the public key can import the new key and remove the old one, and after some re-certification things are back to normal. In comparison, the certificate poisoning attack in 2019 didn't only render the poisoned keys unusable; to my knowledge, it completely broke many users' key management programs (including GnuPG), forcing them to rebuild their keychains from scratch. In a way, the design makes a trade-off by reducing the possibility of a certificate poisoning attack, but increasing the possibility of an unwanted revocation attack. Though given the two attacks' comparative capacity for damage, I personally find such a trade-off to be reasonable. Additionally, to prevent an attack from revoking a large number of public keys en masse, a simple countermeasure would be to have keyservers keep track of how many public keys have been newly revoked during synchronisation. And if an exceptional amount of revocation seems to have occurred, synchronisation can be automatically halted until the keyserver operators manually allow it to continue. This way, if a particular keyserver is compromised and a lot of public keys are revoked, most other keyservers will notice this jump in revocations and stop synchronising with the compromised keyserver, effectively quarantining the attacked keys. From here, the compromised keyserver can be reset, altered, or similar, and then continue operation as normal. This process can significantly mitigate the damage of an unwanted revocation attack due to many of the targeted public keys being prevented from synchronising throughout the network, effectively shielding them from the attack. > I wonder if removing the UID information from a key is enough to be forgotten > (vs the entire key). (Disclaimer: I am *not* a lawyer) I believe it should be enough to satisfy the right to be forgotten. According to Article 4(1) of the GDPR, "?personal data? means any information relating to an identified or identifiable natural person (?data subject?)". By removing all UID data from the public key, the data subject (key owner) is not identified by the key itself. But is the data subject identifiable through the key + some additional research to find external references to the key that relate it to the data subject? Potentially, yes. Though an important detail to note is that for the keyserver to remove UID information from a pubic key, that key must be revoked. And it can be reasonably expected that most or all references to the now-revoked public key would be removed or changed. After all, why would anyone ever want to advertise a revoked key? It's completely useless! As such, it likely can be reasonably assumed that with all UID data removed, the public key neither identifies the data subject, nor does it make the data subject identifiable within reason. > Other than this concern, I think your design is right on. > I can't think of a way to satisfy requirements 4,5,6 without the revocation > certificiates available, and I think this might be the achilles heel here. I can for certain agree that requiring the upload and storage of revocation certificates is the design's main limitation. Both for the reasons you've outlined, and also because it shifts more trust onto keyservers and their operators, which arguably goes against the web of trust's principle of entrusting solely users with the responsibility of managing their own key pairs. But since keyservers act as a middleman for the distribution of public keys, they too likely require at least some (ideally limited) ability to manage said keys in the event of legal intervention. So I mainly view it as a compromise between abstaining from interference of users' keys and adhering to legal obligations. Thank you for the thoughtful feedback, and apologies for the late response. Sincerely,?Seth. PGP Fingerprint 82B9 620E 53D0 A1AE 2D69??6111 C267 B002 0A90 0289 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 343 bytes Desc: OpenPGP digital signature URL: From jb-gnumlists at wisemo.com Wed Jan 29 10:32:03 2025 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Wed, 29 Jan 2025 10:32:03 +0100 Subject: Design of a Modern Keyserver Network In-Reply-To: References: <20345.1737413286@obiwan.sandelman.ca> Message-ID: <63e59fe4-fe26-4771-82ff-7917d9796e73@wisemo.com> > >> I wonder if removing the UID information from a key is enough to be forgotten >> (vs the entire key). > (Disclaimer: I am *not* a lawyer) > > I believe it should be enough to satisfy the right to be forgotten. According > to Article 4(1) of the GDPR, "?personal data? means any information relating to > an identified or identifiable natural person (?data subject?)". By removing all > UID data from the public key, the data subject (key owner) is not identified by > the key itself. But is the data subject identifiable through the key + some > additional research to find external references to the key that relate it to > the data subject? Potentially, yes. Though an important detail to note is that > for the keyserver to remove UID information from a pubic key, that key must be > revoked. And it can be reasonably expected that most or all references to the > now-revoked public key would be removed or changed. After all, why would anyone > ever want to advertise a revoked key? It's completely useless! As such, it > likely can be reasonably assumed that with all UID data removed, the public key > neither identifies the data subject, nor does it make the data subject > identifiable within reason. I am not a lawyer either, but I did do some careful reading of the GDPR a few years ago (It's written in EU-legalese, which seems to be a somewhat backwards notation optimized for machine translation to/from French and German legal documents). As I understand it, UIDs are what the GDPR calls 'pseudonymous' personal data and as such is still subject to some protections .? The 'right to be forgotten' would require an ability of a user to remove any of the their own keys (including the UID) from the keyserver network, also the organizer of the keyserver network, rather than the individual server operators would be deemed the "data controller" subject to most of the legal requirements, and would need to have contracts (electronic would be easiest) with the keyserver operators requiring the keyservers to faithfully perform all requests (including deletions) on behalf of the affected end users, in accordance with the published terms/policy of the "data controller" . There would also be a need to write legal documents about the data sharing between the keyservers and rules banning 3rd parties from making their own copies of public keyserver information that might be handled contrary to the rules in ways that harm users privacy. Beware that some GDPR lawyers are so badly focused on the needs of big data-hoarding companies that they end up giving out bad advice on what the GDPR means (GDPR basically exists to outlaw that data-hoarding, but their day job is to somehow argue that such abuses are legal).? A horror story is how ICANN hired the wrong people to write up the GDPR documents for the WHOIS service and ended up having to censor all the useful information to match their bad legal theories with the law. A much better approach would be to look at how country-wide online phone directories comply with the GDPR, including the fact that most countries will have multiple phone companies that can register and publish numbers etc. assigned to people, while the directory will need to provide a unified cross-provider search that will tell any member of the public what the non-hidden phone number for someone is. Because PGP key servers do not have an ongoing contract with a specific subset of users (there is no ongoing connection service and no ongoing contract payment, so no reason for users to remember which server they uploaded their key to), aspects of the legal framework that presume such provider contracts cannot be used. > I can for certain agree that requiring the upload and storage of revocation > certificates is the design's main limitation. Both for the reasons you've > outlined, and also because it shifts more trust onto keyservers and their > operators, which arguably goes against the web of trust's principle of > entrusting solely users with the responsibility of managing their own key > pairs. But since keyservers act as a middleman for the distribution of public > keys, they too likely require at least some (ideally limited) ability to manage > said keys in the event of legal intervention. So I mainly view it as a > compromise between abstaining from interference of users' keys and adhering to > legal obligations. Indeed, revocation certificates should, as a long standing best practice, and to comply with the data-minimization requirements of the GDPR, NOT be stored until published by the user. There will need to be a clear distinction between revocation and delisting, as a user could want to delist a still valid key, or leave a revoked key listed (to spread the revocation notice). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From mcr at sandelman.ca Thu Jan 30 12:29:46 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 30 Jan 2025 12:29:46 +0100 Subject: Design of a Modern Keyserver Network In-Reply-To: References: <20345.1737413286@obiwan.sandelman.ca> Message-ID: <431767.1738236586@dyas> I was awake a bunch last night, and I was pondering the six points that Seth made. I am more and more concerned with having key servers have access to revocation (certificates), and I have no understanding how this will work with key server to key server communication. It seems to me that there is no way to keep those revocation blobs from becoming public, and therefore abused. That seems the biggest risk to me. I think that that the place where we actually need to differ from the past is actually the flood-fill between key servers. I think that's probably not going to work. Effectively, each key server (organization) needs to make contact with the key owner to establish right to publish key. And that needs to expire. Autocrypt seems like the right way for key servers to interact with users. Effectively, what we want is a kind of STAR: Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) RFC 8739 specifically, keyservers will stop publishing keys that they can't confirm that the user actually still wants published. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From andrewg at andrewg.com Thu Jan 30 16:00:32 2025 From: andrewg at andrewg.com (andrewg) Date: Thu, 30 Jan 2025 15:00:32 +0000 Subject: Design of a Modern Keyserver Network In-Reply-To: <431767.1738236586@dyas> References: <20345.1737413286@obiwan.sandelman.ca> <431767.1738236586@dyas> Message-ID: <54da9daaa50d70f6c8b3e9c2f1ee9968@andrewg.com> On 2025-01-30 11:29, Michael Richardson wrote: > > I think that that the place where we actually need to differ from the > past is > actually the flood-fill between key servers. I think that's probably > not > going to work. Speaking for the current SKS keyserver operators, it *is* currently working. There are occasional glitches when vandals find a way around our flooding protections, but we are constantly improving these. (I realise I'm tempting fate by saying this...) > Autocrypt seems like the right way for key servers to interact with > users. > Effectively, what we want is a kind of STAR: > > Support for Short-Term, Automatically Renewed (STAR) Certificates in > the > Automated Certificate Management Environment (ACME) > RFC 8739 > > specifically, keyservers will stop publishing keys that they can't > confirm > that the user actually still wants published. It's a good idea in principle, but the practicalities of getting continually refreshed consent to publish are currently prohibitive. ACME works because the end user (i.e. the server operator) has an automated job that periodically polls the issuer (e.g. letsencrypt) for fresh certifications, and the issuer can validate the request by making a simple HTTP request that the user does not need to be aware of. This does not translate well to email, which is a fundamentally interactive protocol. It is true that enigmail used to automatically handle WKS verification emails, but this did not catch on elsewhere (unfortunately!) and having multiple keyservers send out such verifications on a recurring schedule would quickly become annoying (and potentially get a keyserver blacklisted). A From jw at raven.inka.de Fri Jan 31 00:15:18 2025 From: jw at raven.inka.de (Josef Wolf) Date: Fri, 31 Jan 2025 00:15:18 +0100 Subject: Please help verify signature within Dockerfile Message-ID: <20250130231518.GX30202@raven.inka.de> Hello all, I am trying to verify signature of downloaded files when creating a docker container. This is what I am trying to do within the Dockerfile: RUN gpg -v --status-fd 1 --no-keyring \ --trust-model always \ --recipient-file /pubkes/release-key.txt \ --verify sigfile.asc foo.tar.gz This errors with "gpg: Can't check signature: No public key". Using strace, I can see that gpg won't even try to open /pubkeys/release-key.txt I also tried to de-armor the pubkey file and pass it as RUN gpg --yes -o release-key.gpg --dearmor release-key.txt RUN gpg -v --status-fd 1 --no-keyring \ --trust-model always \ --no-keyring --keyring /pubkes/release-key.gpg \ --verify sigfile.asc foo.tar.gz with exactly the same result: gpg won't even try to open the keyfile. I also tried to import the pubkey and verify using the default keyring: RUN gpg --import ql/release-key.txt RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp but this one tries to start and connect to gpg-agent, which fails: [1/2] STEP 17/21: RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp gpg: Signature made Wed Jan 28 21:13:26 2015 UTC gpg: using RSA key 307965AB028B5FF7 gpg: Note: database_open 134217901 waiting for lock (held by 3) ... gpg: Note: database_open 134217901 waiting for lock (held by 3) ... gpg: Note: database_open 134217901 waiting for lock (held by 3) ... gpg: Note: database_open 134217901 waiting for lock (held by 3) ... gpg: Note: database_open 134217901 waiting for lock (held by 3) ... gpg: keydb_search failed: Operation timed out gpg: Can't check signature: No public key Error: building at STEP "RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp": while running runtime: exit status 2 BTW: I create an empty ~/.gnupg directory before the very first gpg invocation to prevent use-keyboxd option to be set. Does it really need to be that hard to verify signature with a given pubkey? Any help? -- Josef Wolf jw at raven.inka.de From andrewg at andrewg.com Fri Jan 31 10:57:24 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 31 Jan 2025 09:57:24 +0000 Subject: Please help verify signature within Dockerfile In-Reply-To: <20250130231518.GX30202@raven.inka.de> References: <20250130231518.GX30202@raven.inka.de> Message-ID: <6946B416-8748-4310-881B-9EA4C9E2A03F@andrewg.com> On 30 Jan 2025, at 23:15, Josef Wolf wrote: > > I am trying to verify signature of downloaded files when creating a docker > container. This is what I am trying to do within the Dockerfile: Hi, Josef. Perhaps it would be easier to use gpgv? https://www.gnupg.org/documentation/manuals/gnupg/gpgv.html A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jw at raven.inka.de Fri Jan 31 11:39:43 2025 From: jw at raven.inka.de (Josef Wolf) Date: Fri, 31 Jan 2025 11:39:43 +0100 Subject: Please help verify signature within Dockerfile In-Reply-To: <6946B416-8748-4310-881B-9EA4C9E2A03F@andrewg.com> References: <20250130231518.GX30202@raven.inka.de> <6946B416-8748-4310-881B-9EA4C9E2A03F@andrewg.com> Message-ID: <20250131103942.GY30202@raven.inka.de> On Fri, Jan 31, 2025 at 09:57:24AM +0000, Andrew Gallagher wrote: > On 30 Jan 2025, at 23:15, Josef Wolf wrote: > > > > I am trying to verify signature of downloaded files when creating a docker > > container. This is what I am trying to do within the Dockerfile: > > Perhaps it would be easier to use gpgv? > > https://www.gnupg.org/documentation/manuals/gnupg/gpgv.html Thanks for the pointer, Andrew! This works. Just one addiotional note: gpgv don't have --recipient-file switch, so the pubkey needs to be de-armored: RUN gpg --yes -o release-key.gpg --dearmor release-key.txt RUN gpgv --keyring ./release-key.gpg sigfile.asc foo.tar.gz A --recipient-file (or --public-key-asc-file or something) would be a nice addition to gpgv Thanks! -- Josef Wolf jw at raven.inka.de From tmz at pobox.com Fri Jan 31 15:23:30 2025 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 31 Jan 2025 09:23:30 -0500 Subject: Please help verify signature within Dockerfile In-Reply-To: <20250131103942.GY30202@raven.inka.de> References: <20250130231518.GX30202@raven.inka.de> <6946B416-8748-4310-881B-9EA4C9E2A03F@andrewg.com> <20250131103942.GY30202@raven.inka.de> Message-ID: Josef Wolf wrote: > On Fri, Jan 31, 2025 at 09:57:24AM +0000, Andrew Gallagher wrote: >> On 30 Jan 2025, at 23:15, Josef Wolf wrote: >>> >>> I am trying to verify signature of downloaded files when creating a docker >>> container. This is what I am trying to do within the Dockerfile: >> >> Perhaps it would be easier to use gpgv? >> >> https://www.gnupg.org/documentation/manuals/gnupg/gpgv.html > > Thanks for the pointer, Andrew! This works. Just one addiotional note: gpgv > don't have --recipient-file switch, so the pubkey needs to be de-armored: > > RUN gpg --yes -o release-key.gpg --dearmor release-key.txt > RUN gpgv --keyring ./release-key.gpg sigfile.asc foo.tar.gz > > A --recipient-file (or --public-key-asc-file or something) would be a nice > addition to gpgv https://dev.gnupg.org/T2290 (Allow gpgv2 to use armored GPG keys as keyring file with trusted keys) is a similar wishlist item. It's quite old, so I don't know that anyone who can fix it has the time or desire. But it would make using gpgv nicer. -- Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From mcr+ietf at sandelman.ca Fri Jan 31 14:34:58 2025 From: mcr+ietf at sandelman.ca (Michael Richardson) Date: Fri, 31 Jan 2025 14:34:58 +0100 Subject: Design of a Modern Keyserver Network In-Reply-To: <54da9daaa50d70f6c8b3e9c2f1ee9968@andrewg.com> References: <20345.1737413286@obiwan.sandelman.ca> <431767.1738236586@dyas> <54da9daaa50d70f6c8b3e9c2f1ee9968@andrewg.com> Message-ID: <504932.1738330498@dyas> andrewg wrote: > Speaking for the current SKS keyserver operators, it *is* currently > working. There are occasional glitches when vandals find a way around > our flooding protections, but we are constantly improving these. (I > realise I'm tempting fate by saying this...) But, today, you don't keep/flood revocations, right? >> specifically, keyservers will stop publishing keys that they can't >> confirm that the user actually still wants published. > It's a good idea in principle, but the practicalities of getting > continually refreshed consent to publish are currently > prohibitive. ACME works because the end user (i.e. the server operator) I think that it can't happen unless it's automated. Whether autocrypt or something else. > not need to be aware of. This does not translate well to email, which > is a fundamentally interactive protocol. It is true that enigmail used > to automatically handle WKS verification emails, but this did not catch > on elsewhere (unfortunately!) and having multiple keyservers send out > such verifications on a recurring schedule would quickly become > annoying (and potentially get a keyserver blacklisted). Let's take this to openpgp at ietf.org. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From sgh at erghfe.com Fri Jan 31 18:01:54 2025 From: sgh at erghfe.com (sgh at erghfe.com) Date: Sat, 1 Feb 2025 01:01:54 +0800 Subject: Error generating subkey in gpg's batch mode using curve brainpoolP512r1 Message-ID: Hi! Using the curve brainpoolP512r1 to generate subkeys for signing and verification for a key reports an error, using the following command: printf "$pass" | \ gpg --batch --pinentry-mode=loopback --passphrase-fd 0 \ --quick-add-key $fpr brainpoolP512r1 sign 0 Output: gpg: Key generation failed: Wrong key usage The brainpoolP512r1 curve supports signing and encryption via https://wiki.gnupg.org/ECC. In the above command, subkeys can be generated normally when usage is encr, but using sign and auth will prompt the ?gpg: Key generation failed: Wrong key usage?. Subkeys with signatures and authentication can be added normally through the --full-generate-key interaction mode. Is this an incorrect Gnupg configuration or a bug?