On Tue, Jul 30, 2024 at 10:27:48AM -0500, Orie Steele wrote: > On Tue, Jul 30, 2024 at 9:46 AM Ilari Liusvaara <[email protected]> > wrote: > > > On Tue, Jul 30, 2024 at 08:52:09AM -0500, Orie Steele wrote: > > > The intention is to register the same algorithms. > > > > > > Pre-hash algorithms should be treated the same way, but because COSE and > > > JOSE has algorithm as optional, unless there is domain separation in the > > > public keys, that would be application later alignment. > > > > One problem with supporting pre-hash algorithms is that the current key > > type specified in PQ signature drafts is incompatible with pre-hashing. > > > > How so? > > If there is no domain separation in public keys, then the same public key > can be used for both pre-hash and regular ML-DSA right?
Not just pre-hash/regular, but also with all kinds of pre-hashes. > COSE and JOSE expressions of that key would normally rely on the algorithm > identifier, which currently we do not register any algorithms for pre-hash > (hence it is not supported). Not supporting pre-hash makes things simpler. It also does not encourage signing large things that are difficult for receivers to handle in safe way. Additionally, pre-hash is less useful with ML-DSA than with SLH-DSA or Falcon, due to how ML-DSA works internally. Namely, ML-DSA does support Init-Update-Finalize signing even without pre-hash. Plus, the hash is not hash of data, because both COSE and JOSE prepend stuff, and JOSE additionally base64url-encodes the whole thing. > To support it, we would add a new algorithm identifier like "alg": > "ML-DSA-44-PH" to distinguish public keys used for pre-hash from public > keys used for traditional "alg": "ML-DSA-44". > > If there is domain separation in public keys we might add a new kty for PH > keys, like: "kty": "ML-DSA-PH" It is not just prehash versus not, it is also the prehash algorithm used. And one does not need split by kty, but by whatever specifies the key subtype (like the horribly named "crv" for OKP). > > > Imo, it would be good to have the domain separation in the keys as > > > signatures and not rely on application layer signaling. > > > > There already is domain separation in signatures, which prevents any > > attacks apart from weak pre-hashes. > > > > Right, which means new algorithms are required for COSE / JOSE to support > PH variants. > > If domain separation is added to keys, we would need new key types as well. > > Does this match your understanding? Only new key subtypes, not new key types, but mostly yes. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
