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 <https://keys.openpgp.org/upload/submit>:
>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
>[...]
>
>[...]
> <p><strong>Error</strong>: Parsing of key data failed.</p>
>[...]
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250101/ff383b4d/attachment.sig>
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: <ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250102/5e5c9c45/attachment-0001.bin>
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: <ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
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>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
<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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250102/f134d0f6/attachment.sig>
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>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
<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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250102/1f7588b1/attachment.sig>
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>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
<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>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
<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: <ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
Message-ID: <44d47cb3-0050-a956-97be-df6c6ab4d0f5@anonymous.sex>
On Thu, 2 Jan 2025 19:25:01 -0500, Robert J. Hansen <rjh at sixdemonbag.org> 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)
<https://www.openssh.com/txt/release-8.9>, and it did by default from
v9.0 (2022-04-08) <https://www.openssh.com/txt/release-9.0>. 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250103/5af01058/attachment-0001.sig>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250103/aa6f8250/attachment.sig>
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>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
<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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250103/d049df52/attachment.sig>
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>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
<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>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
<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: <d644002a-d128-42bb-931d-97b486fec179@sixdemonbag.org>
> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250103/3d98e2ea/attachment-0001.sig>
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>
<f7101932-810c-420d-b5b7-2df412e3ed33@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: <d644002a-d128-42bb-931d-97b486fec179@sixdemonbag.org>
References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
<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>
<d644002a-d128-42bb-931d-97b486fec179@sixdemonbag.org>
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: <IDDI6GW4.5LEY2AYH.C3KWCCKJ@2RZUBTHT.E6DA743S.5MZDLOZF>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250105/45bd6099/attachment.sig>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250106/6b462af4/attachment.sig>
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: <a337c93b-d7ab-452d-aebb-2ae6967f5b56@my.amazin.horse>
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 <gnupg-users at gnupg.org> 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 <mcr+IETF at sandelman.ca> . 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250106/cf98a26c/attachment.sig>
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 <gnupg-users at gnupg.org> 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: <ac851a7c-e7ee-265d-a065-ef5252733415@anonymous.sex>
On Mon, 06 Jan 2025 09:09:28 +0100, Werner Koch <wk at gnupg.org> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/4732a382/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 297 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/4732a382/attachment.sig>
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: <ac851a7c-e7ee-265d-a065-ef5252733415@anonymous.sex>
References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex>
<6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex>
<87msg4weh3.fsf_-_@jacob.g10code.de>
<ac851a7c-e7ee-265d-a065-ef5252733415@anonymous.sex>
Message-ID: <be56756c-5230-4cc0-88a1-8ded7d7f0e9c@sixdemonbag.org>
> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/996376f2/attachment.sig>
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
<steffen at sdaoden.eu> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/4732a382/attachment.key>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/7a0e98fe/attachment.sig>
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: <a337c93b-d7ab-452d-aebb-2ae6967f5b56@my.amazin.horse>
References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex>
<6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex>
<87msg4weh3.fsf_-_@jacob.g10code.de>
<a337c93b-d7ab-452d-aebb-2ae6967f5b56@my.amazin.horse>
Message-ID: <32cb8ad5-46d7-9554-8752-15cc406b8f55@anonymous.sex>
On Mon, 6 Jan 2025 10:53:43 +0100, Vincent Breitmoser
<look at my.amazin.horse> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/a3b5edca/attachment.sig>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/611f7db2/attachment.sig>
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: <be56756c-5230-4cc0-88a1-8ded7d7f0e9c@sixdemonbag.org>
References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex>
<6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex>
<87msg4weh3.fsf_-_@jacob.g10code.de>
<ac851a7c-e7ee-265d-a065-ef5252733415@anonymous.sex>
<be56756c-5230-4cc0-88a1-8ded7d7f0e9c@sixdemonbag.org>
Message-ID: <96276a53-5c81-9654-9cc3-cc33ab99f5a3@anonymous.sex>
On Tue, 7 Jan 2025 00:32:36 -0500, Robert J. Hansen
<rjh at sixdemonbag.org> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/9daf96a2/attachment-0001.sig>
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: <ac851a7c-e7ee-265d-a065-ef5252733415@anonymous.sex>
References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex>
<6fd00206-38ca-db5b-a655-1c389df023f8@anonymous.sex>
<87msg4weh3.fsf_-_@jacob.g10code.de>
<ac851a7c-e7ee-265d-a065-ef5252733415@anonymous.sex>
Message-ID: <20250107154012.24aee9b0@incubator.example.net>
On Tue, 7 Jan 2025 04:09:52 +0000
have--- via Gnupg-users <gnupg-users at gnupg.org> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/95044e37/attachment.sig>
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 <fg.gnupg at shimps.de> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250110/4b06cb57/attachment.sig>
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: <ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
References: <6278b0a6-ca72-f459-bedf-42947b596c44@anonymous.sex>
<ef0d6776-07b2-49a4-a96e-e000c4302f8f@sixdemonbag.org>
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: <Z4SuyFnG5m0g4iY9@sinister.lan.codevat.com>
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 <https://gnupg.org/download/> 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
<https://gnupg.org/download/mirrors.html>. 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250114/9a76db2c/attachment.sig>
-------------- 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: <AS8PR02MB7031E32B56FB41581E95AEE18C182@AS8PR02MB7031.eurprd02.prod.outlook.com>
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: <AS8PR02MB70311F04E9231A949A9DF6BE8C182@AS8PR02MB7031.eurprd02.prod.outlook.com>
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: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250117/5701010d/attachment.sig>
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: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
References: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
Message-ID: <60719CA9-5AD4-45F8-A03A-06AEAFDFAFD0@andrewg.com>
Hi, Seth.
On 17 Jan 2025, at 22:59, Seth McDonald via Gnupg-users <gnupg-users at gnupg.org> 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 <http://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 <https://hockeypuck.io/>). In the meantime, keys.openpgp.org <http://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 <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://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore/-/issues/2>
* 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250118/bdd1f566/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250118/bdd1f566/attachment.sig>
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: <wEopQZBCaWHlHrHdOdJ82Hds9RpA8r6qW_T9SgrjKeZN5wSt7TOfhNUw7nfK5Ct9d8DfOt_onpU2q8yCHN1wmajMe-oOkAuwiWI_KrKMJV4=@proton.me>
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: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
References: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250120/2b5f25c1/attachment.sig>
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: <Z5DJIBTa/5yA6c6e@pureos>
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 <service at vhv.de> -----
Date: Wed, 22 Jan 2025 10:55:58 +0100
From: VHV Versicherungen <service at vhv.de>
To: "guru at unixarea.de" <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250122/d37c29fb/attachment-0001.pgp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encrypted.asc
Type: application/octet-stream
Size: 1998 bytes
Desc: OpenPGP encrypted message
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250122/d37c29fb/attachment-0001.obj>
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: <Z5DJIBTa/5yA6c6e@pureos>
References: <Z5DJIBTa/5yA6c6e@pureos>
Message-ID: <20250122150327.4e5e2483@zbook>
Am Wed, 22 Jan 2025 11:32:00 +0100
schrieb Matthias Apitz <guru at unixarea.de>:
> 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: <Z5DJIBTa/5yA6c6e@pureos>
References: <Z5DJIBTa/5yA6c6e@pureos>
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 <service at vhv.de> -----
>
> Date: Wed, 22 Jan 2025 10:55:58 +0100
> From: VHV Versicherungen <service at vhv.de>
> To: "guru at unixarea.de" <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: <Z5DJIBTa/5yA6c6e@pureos>
<20250122150327.4e5e2483@zbook>
Message-ID: <Z5EPrroFZ+JC0Y+a@pureos>
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 <guru at unixarea.de>:
>
> > 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) <guru at unixarea.de>"
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) <guru at unixarea.de>"
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: <Z5EPrroFZ+JC0Y+a@pureos>
References: <Z5DJIBTa/5yA6c6e@pureos> <20250122150327.4e5e2483@zbook>
<Z5EPrroFZ+JC0Y+a@pureos>
Message-ID: <3AEF5D91-9322-4C1F-86A8-ECE64DB5C8B3@andrewg.com>
On 22 Jan 2025, at 15:33, Matthias Apitz <guru at unixarea.de> 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) <guru at unixarea.de <mailto:guru at unixarea.de>>"
>
> 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) <guru at unixarea.de <mailto:guru at unixarea.de>>"
> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250122/4ec8a507/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250122/4ec8a507/attachment-0001.sig>
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: <Z5DJIBTa/5yA6c6e@pureos> (Matthias Apitz's message of "Wed, 22
Jan 2025 11:32:00 +0100")
References: <Z5DJIBTa/5yA6c6e@pureos>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250122/b367206f/attachment.sig>
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: <Z5DJIBTa/5yA6c6e@pureos> <20250122150327.4e5e2483@zbook>
<Z5EPrroFZ+JC0Y+a@pureos>
<3AEF5D91-9322-4C1F-86A8-ECE64DB5C8B3@andrewg.com>
Message-ID: <Z5EmSwXYA_o6nxYT@c720-1400094>
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: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
<20345.1737413286@obiwan.sandelman.ca>
Message-ID: <OLFjzYe279cG2TvtehAV4-pl3nAjSRNEYiF-MWRQ0Ptz59gPO0cSia60TwXznZaCg0A2lK64XlKUSU4FJo_DUvXLk9OTBE7nFObKzWc7VQs=@pm.me>
> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250127/d22113cc/attachment.sig>
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: <OLFjzYe279cG2TvtehAV4-pl3nAjSRNEYiF-MWRQ0Ptz59gPO0cSia60TwXznZaCg0A2lK64XlKUSU4FJo_DUvXLk9OTBE7nFObKzWc7VQs=@pm.me>
References: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
<20345.1737413286@obiwan.sandelman.ca>
<OLFjzYe279cG2TvtehAV4-pl3nAjSRNEYiF-MWRQ0Ptz59gPO0cSia60TwXznZaCg0A2lK64XlKUSU4FJo_DUvXLk9OTBE7nFObKzWc7VQs=@pm.me>
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: <CAJj0Out5UodviypndMrp7sDUbZP5MkKd75KMBh2nmc7t-9wifw@mail.gmail.com>
References: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
<20345.1737413286@obiwan.sandelman.ca>
<OLFjzYe279cG2TvtehAV4-pl3nAjSRNEYiF-MWRQ0Ptz59gPO0cSia60TwXznZaCg0A2lK64XlKUSU4FJo_DUvXLk9OTBE7nFObKzWc7VQs=@pm.me>
<CAJj0Out5UodviypndMrp7sDUbZP5MkKd75KMBh2nmc7t-9wifw@mail.gmail.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250130/7ab6bdd4/attachment.sig>
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: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
<20345.1737413286@obiwan.sandelman.ca>
<OLFjzYe279cG2TvtehAV4-pl3nAjSRNEYiF-MWRQ0Ptz59gPO0cSia60TwXznZaCg0A2lK64XlKUSU4FJo_DUvXLk9OTBE7nFObKzWc7VQs=@pm.me>
<CAJj0Out5UodviypndMrp7sDUbZP5MkKd75KMBh2nmc7t-9wifw@mail.gmail.com>
<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 <jw at raven.inka.de> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250131/7aa22021/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250131/7aa22021/attachment.sig>
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 <jw at raven.inka.de> 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: <Z5zc4sw57ZnVYKCG@teonanacatl.net>
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 <jw at raven.inka.de> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250131/f400948e/attachment.sig>
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: <nIZ8xYQi4Dwj1Y8K561gvzG6B-E0EnKUAAo2FIr6RvNzIw1QbDtsis6sQGciL5rvJzb1kZnbZ1NsVINzoBkbUYOW_1qz7Kzg8cGic6hBVMo=@pm.me>
<20345.1737413286@obiwan.sandelman.ca>
<OLFjzYe279cG2TvtehAV4-pl3nAjSRNEYiF-MWRQ0Ptz59gPO0cSia60TwXznZaCg0A2lK64XlKUSU4FJo_DUvXLk9OTBE7nFObKzWc7VQs=@pm.me>
<CAJj0Out5UodviypndMrp7sDUbZP5MkKd75KMBh2nmc7t-9wifw@mail.gmail.com>
<431767.1738236586@dyas> <54da9daaa50d70f6c8b3e9c2f1ee9968@andrewg.com>
Message-ID: <504932.1738330498@dyas>
andrewg <andrewg at andrewg.com> 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 <mcr+IETF at sandelman.ca>, 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250131/4dcbf8f6/attachment.sig>
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: <FF102985-92FE-4A9B-A301-01160CD12C83@erghfe.com>
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?