GnuPG meets the standard of care set by Signal (Re: Betamax v. VHS, and the future of PQ-PGP)

[have at 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>