ML-KEM adoption is now starting to outpace IPv6 adoption. The Post-Quantum League of Evil warns:
A successful migration should be a properly paced one. Anything faster than IPv6 is suspect.
PQC League of Evil
- 62 Followers
- 0 Following
- 11 Posts
For too long have these do-gooders at the PQC Alliance and the PQC Consortium had a beneficial influence on PQC migration. A counterweight is needed. The PQC League of Evil is here to provide it.
Alexander Sosedkin 
@pqcloe instructions unclear, without a standardized 'None of the above' nothing accepts my The_Matrix_Reloaded_2003.mkv.pem
Chris@pqcloe For maximum flexibility in the future, the key format choice should be decided by an extension
Urgent release by the PQ League of Evil:
Private key formats for ML-KEM and ML-DSA have been hotly debated recently. We at the league have discovered a missing perspective in the discussion: while the expanded private key format contains most information, it misses the matrix itself, which should be possible to store as well. Therefore, we suggest the following solution:
ASN.1 CHOICE of:
Seed
Expanded private key
Extra expanded private key
Both
More both
Extra both
All
We already have modules in the validation pipeline that only support extra expanded private keys, and it would be unfair to us early adopters to not standardize like this!
Of course, we are aware of the concerns that keys might contain redundant data. To address this, implementers SHOULD randomly flip bits in some of the keys before loading.
Cryptographic Agility is essential for the upcoming PQC migration. Today we will reveal our draft for a new RFC that should improve the lack of agility in protocols like TLS.
First, in ClientHello, our proposed extension will add a new field, where the client states which Cryptographic Agility Configuration Languages (CACL) they support. Initially, clients MUST support brainfuck and SHOULD support whitespace and Perl as secondary CACLs.
The server then chooses a CACL and responds with its Cryptographic Algorithm Agility Suites (CAAS) specified in the desired CACL. The client will check whether any of the specified CAAS is in its list of preferred algorithms (we haven't looked too deeply at this part, but how hard could it be?), and if necessary suggest further CAAS for the server to consider until agreement is reached.
With this, we will finally achieve full agility for key agreement schemes, not requiring any changes to the protocol in case new algorithms are proposed. Similar approaches can also be applied to the key derivation, the record layer encryption, and even the server's application logic itself.
Tobias Heider
Damien MillerDrafting my Star Wars script for Disney's consideration. It centers on the character of Sha Kem, a young Jedi who takes their X-Wing to find some Kyber crystals.
I look forward to being able to find details about Kem and their Kyber easily using internet search engines. @pqcloe
@pqcloe finally, the right organisation to advance my PQ dh-modp65536-kem proposal
We are proud to announce the formation of the PQC League of Evil.
For too long have do-good organizations like the PQC Alliance or the PQC Consortium had a beneficial influence on the PQC standardization process and migration. No more! The PQC League of Evil is here to finally inject some evilness into the discussion, to counteract this obvious imbalance.
We have several exciting projects planned, stay tuned for more information.