SHAKE256 supports streaming. It's a sponge construction, you only need to keep the sponge as state, and can stream in the data.
On Wed, Sep 25, 2024 at 4:24 PM Phillip Hallam-Baker <[email protected]> wrote: > 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] >> > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
