On Tue, Jul 29, 2025 at 02:07:04PM +0200, Falko Strenzke wrote: > I made a review of draft-lundberg-cose-two-party-signing-algs-02 > <https://www.ietf.org/archive/id/draft-lundberg-cose-two-party-signing-algs-02.html> > > My first comment is on the novelty or relevance of the contents. In the > abstract, the text says that the document introduces “split signing > algorithms”. This term is meant to refer to splitting the hashing of the > message, resulting in the message digest, and the signature operation > performed on the message digest among two so called “entities”, the digester > and the signer. Such a splitting of these operations in an implementation is > neither new nor does it necessarily require an explicit specification. > Rather, whether of not the hashing and signature operation can be conducted > in separate cryptographic modules would be addressed by a possible > certification scheme that an implementation has to adhere to. Otherwise such > a separation seems to be an implementation detail that typically has no > relevance for interoperability.
Furthermore, I think the approach presented in the draft is not a good one to solve the underlying issue (dealing with large payloads). I think much better approach would be to hash the payload (perhaps with salting) before signing. Note that this is subtly different from what hash-envelope does (which is to replace the payload with hash of it). > Security-wise, I would like to point out that it is necessary that with the > introduction of the split signing algorithms no ambiguity is created as to > whether a specific signature algorithm is applied to the message directly or > the message digest. If that was the case, then an attacker could potentially > exchange the directly signed message with a hash of the message without > invalidating the signature. > > With respect to PureEdDSA, it is not clear to me whether or not such a > problem is introduced by the draft. Specifically it says: > > “The signer executes the PureEdDSA signing procedure, where the value > denoted M in the PureEdDSA signing procedure takes the value denoted PH(M) > in the EdDSA signing procedure.” > > The newly defined COSE algorithm identifier Ed25519ph (where Ed25519ph would > still have to be registered (?) together with Ed25519ph-split) defined in > this draft would conflict in this sense with EdDSA as it is already defined > in COSE: Both these algorithm IDs internally use PureEdDSA, and thus the > said ambiguity would arise. > > This problem was solved if COSE signatures would include the signature > algorithm ID as meta data. But I can’t read that such a field exists in > COSE. If the signature algorithm ID is included at all (instead of left implicit), then it is included in metadata (since alg MUST be protected if possible, and it is always possible with signatures). However, that does not protect against mechanisms that bypass COSE entirely. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
