All, I am looking for guidance on algorithm identifiers for ML-KEM and ML-DSA, I understand that the drafts are not yet final. But I need to push code that has PQC roots embedded before that is going to happen and would like to follow as close as possible to what the final choices are going to be.
I did try to look for this info but the work is spread thinly across many forums... My preference is for fully specified algorithms with the strength specified. I am also partial to longer rather than smaller identifiers but that does not seem to be to the taste here. So my IDs would be MLKEM512 MLKEM768 MLKEM1024 MLDSA44 MLDSA65 MLDSA87 If we want to go denser: MLK512 MLK768 MLK1024 MLD44 MLD65 MLD87 Actually, I like the second as they are more readable. I have been reading a large number of tweets by an elderly person who types in all caps online of late... Since I need to ship before the specs are final, I will probably use: MLKa1024 MLDa87 I see no need for other identifiers since I cannot imagine anyone who is so concerned about CRQC robustness as to use PQC not using the highest strength available at this point. Also, I want to stress test with the biggest payloads. Signing every message with MLD87 turns out to have a very serious impact. And not one I think I can justify for every application when a CRQC is still at least a decade out. So the real goal at this point is to ensure that if people start deploying the system and make use of it today, they know they can transition seamlessly to a PQC version of everything in the future. Turns out that costs only an extra 200 bytes or so in the user profiles! And before folk start whining about me mentioning my work on the Mesh, the point of building a completely green field infrastructure is to test out design approaches which we might attempt to retrofit to PKIX and SAML.
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
