I agree. New crypto systems should follow the standard for "kty":
https://datatracker.ietf.org/doc/html/rfc7517#section-4.1
The "kty" (key type) parameter identifies the cryptographic algorithm
family used with the key, such as "RSA" or "EC"
Putting different PQ crypto systems under the same moniker would be a mistake
regardless of the system's maturity.
Distinct names permit dynamic registration of cryptographic providers which is
used by platforms like Java.
The exact naming I leave to the committee to figure out :)
Cheers,
Anders
On 2022-07-06 9:19, Ilari Liusvaara wrote:
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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
