On Tue, Jul 05, 2022 at 02:45:00PM -0500, Orie Steele wrote: > Hello, > > We've been working on JOSE/COSE representations for post quantum > cryptography here: > > https://mesur-io.github.io/post-quantum-signatures/draft-prorock-cose-post-quantum-signatures.html > https://github.com/mesur-io/post-quantum-signatures > > Given the recent announcement: > > Announcement: The End of the 3rd Round - the First PQC Algorithms to > be Standardized > - https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/G0DoD7lkGPk?pli=1 > > We'd like to share our progress, gather feedback and discuss next > steps.
Some feedback: - I really do not like the PQK kty. It might be desirable to define a new keyshape that is explicitly single-algorithm by using alg for algorithm selection, with octet string private/public keys. However, I really do not think PQK is good name for that. Additionally, PQK makes no sense as some sort of grouping of algorithms, as post-quantum is very diverse bunch, especially with signatures (I think there are like 4-5 very different types). And post-quantum is not only signatures. - The "pset" parameter makes no sense to me. Dilithium 2, 3 and 5 are not compatible at all, even if implementations may internally share code. Same for Falcon and SPHINCS+ variants. This incompatiblity makes all these "variants" to actually be different algorithms. This is not like ECC, where ECDSA is compatible between different hash functions (and the same for ECDH). If one wants a precedent for this type of incompatiblity, there is EdDSA (Ed25519 and Ed448). - There are serious security concerns about Dilthium and Falcon at this point (there are no concerns about SPHINCS+). There is wide consensus that the way to counter these concerns is to hybridize with "classical" algorithm. And given that post-quantum stuff seems to really like SHAKE, one would want a classical signature that uses SHAKE. Unfortunately, SHAKE in ECDSA is cursed (nasty interop trap), and the only other signature algorithm that uses SHAKE is Ed448, which would not be great for pairing with the low variants. - Even if the algorithms to be standardized are published, there are no guarantees that the final standards will be compatible with the latest versions of the algorithm specifications. - I think at this point, given that CRQCs are not imminent, it makes more sense to focus on encryption first, as it is much more urgent problem. For signatures, it suffices to complete transition by the time CRQCs appear. For encryption, anything less than several decades before causes severe problems. And that time is substantially longer than the ~10 years last signature transition (SHA-1 to SHA-2) took. For encryption, it might be worth to take the risk of producing incompatible transitional algorithm. Any implementation of both the transitional and final algorithms is likely to be able to share very substantial chunks of the code. For signatures, that is much less clear. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
