On Wed, Nov 19, 2025 at 09:55:19AM +0100, Falko Strenzke wrote: > > I generally recommend to use cryptographic algorithms in COSE only through > their external interfaces and according to their specifications in the form > of RFCs or other standards. In case cryptographic algorithms are being > "opened up", in the sense of accessing their internals, or their inputs > redefined or reinterpreted, I suggest to let the design undergo a detailed > review from one or multiple experts in cryptographic engineering. My > existing review doesn't live up to that as I lack knowledge of the > application context and, as I become aware after your response, apparently > don't understand the design and its exact goals.
Thinking more about the design, I do not understand how the stuff from this draft can even work: With these "split" algorithms, the very idea is to pass a hash to signer. Furthermore these algorithms seem to exist for API purposes, and what is passed is very different from normal signatures. This gives these algorithms very magical properties, enough that the algorithms need to be considered reserved from COSE_Sign perspecive (similarly to how JOSE has some algorithms reserved for WebCrypto that are meaningless in JOSE itself). This implies that verifiers MUST NOT support these algorithms. ESP512-split should presumably be ESP521-split, as any parametric hash is irrelevant in this kind of application. For ECDSA, that only leaves the underlying curve, and there is no 512-bit P-curve, it is 521-bit. And HashEdDSA is very poorly supported. I still think that for archiving goals of this (signing data too large to transfer to signer), it would be better to have COSE_sign-level pre- hash extension. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
