On Sat, Oct 18, 2025 at 1:30 AM Robert J. Hansen via Gnupg-users <[email protected]> wrote: > > The why bother; is because it is best option available, for now. > Your proposal has been heard, considered, and soundly rejected. Could we > please return to discussing GnuPG?
I don't care if solely you, some random user on the internet reject it. This is a good way to use gnupg. This is what you have for a solution to the problem in general. What if I want to encrypt a file such that (USERID1), (USERID2), and (USERID3) must all co-operate in order to read the file? Multiple keys necessary to unlock gpg -e -r USERID1 < inputfile.txt | gpg -e -r USERID2 | gpg -e -r USERID3 > output_file.gpg As far as I know there is no better way than that provided by GnuPG as an option. You speak as if you invented the crypto or whatever, and I ever came for approval. The point is I shared best practice to append post-quantum protections, to your security plans, and it is fine if you disagree. That it is now one best practice to add quantum protection, and chain it with addition to existing procedure If the technology is not available to combine that into a single function. Given input -> A -> B -> output. It is reasonable to presume function A's security promises remained intact following processing by an arbitrary function B which does not have inputs available to it related to the inputs of function A. You cannot guarantee it 100%, but a mathematical proof is not the standard to extend security practices which lower compromise probability. You ignore added risks related to future quantum crypto development at your own peril. It's fine to only use PQC, but you ignore other risks the implementation doesn't help you with, also at your own peril. The industry disagrees with you. You'll find the approach appearing in various standards. OpenSSH 10 already changed the default to a combination of ML-KEM with 25519 ec key exchange, mlkem768x25519-sha256, etc. Your rejection is soundly dismissed. -- -JA _______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
