ML-DSAhash is designed to support streaming. That isn't necessary if you only work at the packet layer but you certainly don't want to sign 1TB files using the SHAKE256 construct and pushing all that data into a FIPS-140-3 HSM.
For COSE and JOSE, ML-DSAhash is unnecessary because you are always signing over a manifest. So if you are going to sign a 1TB file, you hash with your favorite digest, specify the digest value and digest algorithm ID in the SighedHeader field and then sign over that. That is exactly what ML-DSA-pure is intended for. For other systems, the reason we need ML-DSAhash is that we have a lot of APIs that are built around the RSA interface of 'sign digest value and OID'. And ML-DSA needs to support a mode where it is a direct drop in substitute. If the digest algorithm identifier is omitted, there is a possibility of a digest substitution attack. So it is an important consideration. The other concern is semantic substitution and there there are two separate issues, one is crafting a CMS package so that it is a legitimate COSE package. Which seems far fetched but so did gifs that render as jpgs... The second is crafting a COSE package for application A so that it is accepted as legitimate by application B. This is a much more plausible attack. If every signature algorithm supported context, we could use the signature context slot for both. Since they don't and since taking data provided by the signer and putting it into the signature envelope directly is 'icky' to say the least, the better way to do this in a standardized envelope that has a manifest is to use the context string to identify the envelope format, 'XML-DIG-SIG', 'JOSE', 'COSE', etc. and make a slot in the envelope manifest for application level separation. This is actually done in the SAML assertion format which has an Audience field for the express purpose of semantic binding to the terms and conditions of the signature. CMS/PKCS#7 is really rooted in the way we did things 30 years ago and the signature context is really the only option. This may seem unnecessarily complex but it is much easier to block this class of attack completely than to spend time auditing every application to see if there is a problem. The way we form the key agreement output doing ECDH (P-256 etc) is a lot more verbose than X25519 because it binds to the keys used for the key agreement. I am really not at all sure what the advantage of doing it that way when your key names are 'Alice' and 'Bob' which is what we have in the RFC but that's what we did and maybe we should have done X25519 exactly the same way so it was the same... On Wed, Sep 25, 2024 at 5:19 PM Sophie Schmieg <sschmieg= [email protected]> wrote: > Note that there are two options for prehashing with ML-DSA: You can use > the comment on algorithm 7, line 6 and use the hash function > SHAKE256(SHAKE256(pk, 64) || 0x00 || 0x00 || m, 64), in which case it works > exactly the same as ECDSA (with a known hash function). I.e. the hash can > be computed elsewhere and transmitted to a signing oracle, producing a > signature that looks the same as if no prehashing has taken place, so from > the verifiers perspective this choice does not matter. Or you use the (in > my opinion strictly worse) option of using HashML-KEM, where you prehash > with say SHA512. In that case, the verifier needs to know that you did so. > By calling that algorithm HashML-DSA-SHA512 (and putting the algorithm > information in the public key), you can communicate that, but honestly I do > not see any reason to do so that would not be better served by just using > ML-DSA, prehashing with the SHAKE256 construction mentioned. > > On Thu, Sep 19, 2024 at 12:34 AM Ilari Liusvaara <[email protected]> > wrote: > >> On Wed, Sep 18, 2024 at 01:50:20PM -0700, Sophie Schmieg wrote: >> > On Tue, Sep 17, 2024 at 1:20 PM Ilari Liusvaara < >> [email protected]> >> > wrote: >> > >> > > >> > > In case of signed JWT, the very first thing that needs to be parsed >> out >> > > is "iss". >> > > >> > > ... Which is a bit problematic. >> > >> > Yeah, I somewhat intentionally did not mention iss, because yeah, it is >> a >> > bit problematic, and forces the "authorization decision passed down to >> > downstream system" as a pattern. >> >> Dedicated JWT validation code could callback to map issuer name to >> keyset. But that runs into bit annoying function color issues in many >> laguages (fortunately synchronous factorization does not seem to be too >> bad)... >> >> >> > > Unfortunately, that runs into problems with pre-hashing. >> > > >> > > Currently, that only gets problematic for RSA, but supporting >> pre-hashed >> > > ML-DSA would also introduce the problem there. >> > > >> > > ECDSA has essentially fixed prehash (ok), and EdDSA in COSE/JOSE does >> > > not support pre-hashing. >> > > >> > >> > I'm not sure I follow. The hash function used with a signature scheme is >> > part of the signature scheme as well, and so the public key should allow >> > you to derive that information. Several common public key serialization >> > formats unfortunately do not properly include the hash function, maybe >> that >> > is what you are referring to? Or do you have a system where the decision >> > which hash function to use is taken independently of the decision of >> which >> > key to use? In that case, yeah you have lots of incompatibilities, >> > especially in the case of ML-DSA where the hash function is fixed to >> > SHAKE256, and has to be prefixed with a hash of the public key, but I'm >> not >> > sure why the algorithm has to be part of the token to enable this use >> case. >> >> Because public keys frequently fail to include hash function, one would >> have to deduce the hash function from the key itself. >> >> That works in practice for ECDSA, EdDSA and HSS-LMS. But it does not >> work for RSA (then there is the PSS versus PKCS#1 v1.5 stuff...). >> >> For ML-DSA, supporting pre-hash mode breaks deducing hash function. >> >> >> >> >> -Ilari >> >> _______________________________________________ >> COSE mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > > -- > > Sophie Schmieg | Information Security Engineer | ISE Crypto | > [email protected] > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
