On Thu, 2 Jan 2025 19:25:01 -0500, Robert J. Hansen <r...@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=37571919Version 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/120As 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/120That’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
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
