On Thu, 2026-02-26 at 12:22 -0500, Stefan Berger wrote: > > On 2/26/26 11:58 AM, Eric Biggers wrote: > > On Thu, Feb 26, 2026 at 10:27:43AM -0500, Simo Sorce wrote: > > > On Thu, 2026-02-26 at 09:16 -0500, Stefan Berger wrote: > > > > On 2/26/26 7:42 AM, Stefan Berger wrote: > > > > > On 2/25/26 7:10 PM, Eric Biggers wrote: > > > > > > On Wed, Feb 25, 2026 at 09:25:43AM -0500, Stefan Berger wrote: > > > > > > > To avoid duplicate work: Is either one of you planning on writing > > > > > > > patches > > > > > > > for IMA to use ML-DSA and convert the current ML-DSA to also > > > > > > > support > > > > > > > HashML? > > > > > > > I had done the work on this before and could dig out the patches > > > > > > > again... > > > > > > > > > > > > IMA already had to add its own digest prefixing support, since it > > > > > > was > > > > > > needed to disambiguate between full-file digests and fsverity > > > > > > digests. > > > > > > See 'struct ima_file_id'. Thus the message signed is at most 66 > > > > > > bytes. > > > > > > > > > > The hash there is still only a hash over a file and that hash is > > > > > signed, > > > > > isn't it? > > > > > > > > > > > > > > > > > With that being the case, HashML-DSA isn't necessary. It's not even > > > > > > possible to use here, since there are no OIDs assigned for the > > > > > > fsverity > > > > > > digests, so it cannot replace the ima_file_id. > > > > > > > > > > For non-fsverify IMA signatures it is 'possible' to use HashML-DSA and > > > > > it's 'working' (recycled old patches yesterday): > > > > > > > > > > Linux: https://github.com/stefanberger/linux/commits/ > > > > > dhmlsa%2Bima.202602025/ > > > > > > > > > > ima-evm-utils: > > > > > https://github.com/linux-integrity/ima-evm-utils/pull/19/ > > > > > commits > > > > > > > > > > > > > > > > > I'll also note that HashML-DSA is controversial (e.g. see > > > > > > https://keymaterial.net/2024/11/05/hashml-dsa-considered-harmful/), > > > > > > > > > > The problem with this is that NIST would have to react to these > > > > > controversies as we race to support PQC. If something is wrong with > > > > > the > > > > > standard then it would be best for NIST to withdraw/modify HashML-DSA > > > > > asap. Otherwise it's the best to follow the standard IMO because if > > > > > you > > > > > don't you get criticism otherwise. > > > > > > > > What I am not clear about from FIPS-204 is whether availability of > > > > HashML-DSA is a "must-use" or a "may-use". What speaks against it for > > > > our use case is performance. The lookup of a hash's ID (last digit of > > > > OID) and the creation of the 11 byte encoding to prepend before every > > > > digest for every signature takes cycles. > > > > > > It is a recommendation, but there are plenty of protocols (TLS, > > > OpenPGP, etc...) where the decision has been made to use "pure" ML-DSA > > > only, even if what you are signing is not the full data, but something > > > containing a hash. > > > > > > Ideally you do not sign *just* a hash, but some structured data, like a > > > context label that identifies the hash and some other related metadata > > > for example. In order to make forgeries much harder should the hashing > > > algorithm used to hash the data weaken over time. But it is not > > > strictly necessary (NIST mentioned in some forum, sorry I do not have > > > the message handy for quoting, that a structured packet is perfectly > > > fine for use with pure ML-DSA, because it does enough to address the > > > same issues that a separate internal context does with HashML-DSA). > > > > > > If pure-ML-DSA works better for IMA, just use pure ML-DSA. > > > > > > > Maybe it should explicitly state in FIPS-204 something along the lines > > > > of "with a given hash either ML-DSA or HashML-DSA can be used (for as > > > > long as you use it in the same way from then on)." At least this way > > > > nobody can point out that HashML-DSA should have been used when you > > > > didn't. > > > > > > NIST will not change the standard documents any time soon, but for FIPS > > > certification there are Implementation Guidelines. > > > > > > In any case a FIPS module cannot distinguish between data that happens > > > to be 32 bytes long and a hash of larger data, so the point is kind of > > > moot. From the FIPS perspective HashML-DSA is just an available > > > algorithm that protocol implementations can use, or not. > > > > > > There are additional guidelines on what this may be useful for, but so > > > far NIST has not objected to the use of pure ML-DSA even where > > > theoretically HashML-DSA could be used. > > > > I see that IMA indeed never upgraded full file hashes to use > > 'struct ima_file_id'. Building a new feature that relies on this seems > > like a bad idea though, given that it's a security bug that makes > the> IMA protocol cryptographically ambiguous. I.e., it means that in IMA, > > when the contents of some file are signed, that signature is sometimes > > also valid for some other file contents which the signer didn't intend. > > You mean IMA should not sign the digest in the ima_file_id structure but > hash the ima_file_id structure in which this file digest is written into > (that we currently sign) and sign/verify this digest?
You should not (need to) hash it, just format it and the use ML-DSA to sign it. > And we would do > this to avoid two different files (with presumably different content) > from having the same hashes leading to the same signature? Which hashes > (besides the non-recommended ones) are so weak now that you must not > merely sign a file's hash? > > The problem with this is that older kernels (without patching) won't be > able to handle newer signatures. Ad a kernel option to use the new format? Old kernels won't be able to deal with ML-DSA IMA either. > > > > Just fix that bug first, which has to be done anyway. Then just use > > pure ML-DSA to sign and verify the 'struct ima_file_id'. > > > As Simo mentioned, FIPS 204 doesn't require HashML-DSA when signing a > > hash. It's there as an *option* to solve a perceived problem, which is > > actually solvable in better ways. > > > > NIST doesn't plan to update FIPS 204 until 2029, and most likely the > > updates will just be errata in the text (such as the ones I reported to > > them), not changes or withdrawals in the algorithms themselves. But > > it's irrelevant: just because HashML-DSA is an option doesn't mean it > > has to be used. Pure ML-DSA supports arbitrary data, which includes > > And I was sure whether it was merely an 'option'. Who would use it then > if it takes more cycles to hash the prepended 11 byte oid in HashML-DSA? Nobody is using HashML-DSA at the moment. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc
