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]
