Things which are PQC (Post Quantum Cryptography) related.
Details
Thu, Jul 3
Wed, Jun 18
Tue, Jun 17
Done in 1.11.1.
Fri, Jun 13
Reading https://openssl-library.org/files/blog/Request_to_Extend_IETF_WGLC_for_PQ_Key_Specifications.pdf ,
seed (with "S") is included in the private-key.
The commit rC23543b6c1497: Add mldsa_compute_keygrip and let private-key include "p". works well for me.
To support Dilithium, we need to extend data handling of libgcrypt.
I propose following changes:
- internal flag of PUBKEY_FLAG_BYTE_STRING to ask opaque MPI for data to be signed/verified.
- The format of data as: (data(raw)[(flags no-prefix)](value ...)[(label ...)][(random-override ...)]): message, context, and random. Optional no-prefix flag to ask specific way of signing, controlling the internal, for Known Answer Tests (siggen).
May 19 2025
Looking the FIPS 204 document, using the following functions (API) is good:
May 15 2025
May 14 2025
Thank you again for the reactivity! Applied, everything seems to work just fine.
For prompting, I pushed a fix in rG45a11327f3bd: agent: Support the use case of composite PQC for prompting.
Thank you for testing.
May 13 2025
Thanks! With that patch applied, decryption works fine.
Thank you for the concrete test case, it helps me.
May 11 2025
May 7 2025
Feb 3 2025
@gouttegd: Good idea. I did this with the above patches.
Jan 8 2025
Jan 3 2025
Change the encryption code to only allow 256 bit session keys with Kyber regardless of the preferences, iff --require-pqc-encryption is set. […] We could as well also encforce AES-256 also without that option.
What if we encrypt to several recipients, only some of them having a Kyber encryption key? Should we still enforce AES-256 in that case regardless of the preferences, and assume that by now everybody should support AES-256?
Love it! I think I am going to use “post-heffalump crypto” from now on. :D
But keep https://www.cs.auckland.ac.nz/~pgut001/pubs/heffalump_crypto.pdf in mind ;-)
Jan 2 2025
I wrote it with PQC security level in mind which requires AES256 for the session key as well.
That is what I expected. Meanwhile I re-read the code and history and can tell that the comment is not correct. I wrote it with PQC security level in mind which requires AES256 for the session key as well. However, during the migration phase and as long as --require-pqc-encryption is not enable we should allow an AES-128 session key. This is for the rare case that encryption is also done for non pqc keys which don't have the AES-256 capability set.
Here you are:
At gnupg/g10/pubkey-enc.c you will find
Dec 13 2024
Dec 5 2024
Dec 4 2024
Works for me in an NSIS installer. The VSD beta thing also works with copied conf files.
(gpg4win-5.0.0-beta27 with some local mods)
Nov 14 2024
Ready for testing. Note that you also need gpgme master.
Oct 8 2024
Pushed the fix for exporting OpenPGP v5 key: rG57dce1ee62c2: common,gpg,scd,sm: Fix for Curve25519 OID supporting new and old.
Oct 3 2024
The OID is used for fingerprint computation, which complicates things.
Oct 2 2024
Using the shorter OID for v5 is on purpose; thus we need to fix the export.
Oct 1 2024
Sep 17 2024
Sep 12 2024
See new subtask T7290 for smartcards and the link entries mentioned above.
Sep 6 2024
Jul 11 2024
We hereby deliver with some delay our completed version of the integration of PQC algorithms into Libgcrypt from our project. The code features the following algorithms: