Re: IMA and PQC

Eric Biggers
2026-02-26T19:44:58Z

On Thu, Feb 26, 2026 at 02:21:41PM -0500, Stefan Berger wrote:
>
>
> On 2/26/26 1:32 PM, Eric Biggers wrote:
> > On Thu, Feb 26, 2026 at 12:22:32PM -0500, Stefan Berger wrote:
> > > > 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? 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.
> >
> > IMA needs to sign the entire ima_file_id structure, which is indeed what
> > IMA already does when it uses that structure. (Well, actually it signs
> > a hash of the struct, but that's best thought of an implementation
> > detail of legacy signature algorithms that can only sign hashes. For a
> > modern algorithm the whole struct should be passed instead.) Just IMA
> > uses that structure only for fsverity hashes, which is a bug that makes
> > the IMA protocol ambiguous. It needs to use ima_file_id consistently,
> > otherwise a signed message sometimes corresponds to multiple unique file
> > contents even without a break in the cryptographic hash function.
>
> Before we jump into making changes on this old stuff I think it's good to
> understand the underlying problem and the likelyhood of signatures
> validating different data, such as a file and fsverity data. How likely is
> this?
>
> Assuming a strong hash I suppose that is not a concern with RSA because here
> the digest is padded and then directly encrypted with the private key. Upon
> verification (pub key decrypt) we would unpad and memcmp the digests.
>
> Again, assuming a strong hash: With ECDSA NIST P256 for example we have a 32
> byte signature. With a SHA512 being used for hashing for example we would be
> doing a projection of a 64byte hash space to a 32byte signature space with.
> Just by this projection of a much larger space into a smaller space
> signatures that validate multiple input data could be a problem. One 'easy'
> case where signatures for different input data is the same (not exactly the
> same due to nonce involved the signature is verifyable), albeit unlikely, is
> that there could be different input data for the SHA512 that lead to the
> same 32bytes prefix, which is then used after truncating the sha512 to the
> first 32 bytes for the ECDSA signature, and this then leads to a signature
> that is verifyable for different input data. So that's the 'simple' case at
> least for this thought experiment for a non-expert.
>
> Now what should still be difficult to do is given a file and a hash-to-use
> that you can create fsverity content that leads to a hash that in turn leads
> to a NIST-P256 signature that can be used for signature verification(s) of
> the file and the totally different fsverity data. Is this a problem that is
> as difficult to solve just as finding different input data for a hash that
> leads to the same digest?

There's no differentiation between a 'struct ima_file_id' that
*represents* the contents of some file, and a file whose contents are
*equal to* that 'struct ima_file_id' and that uses a full-file hash. In
both cases the same key and message are used for signing and verifying.

This means that every time a file is signed using the ima_file_id
scheme, it also implicitly signs some other file contents, which an
attacker can freely replace the file with. Similarly, every time a file
that happens to be a valid ima_file_id is signed using the older scheme,
it also implicitly signs the contents that the ima_file_id correspond
to, which the attacker can freely replace the file with. In either
case, no collision in the cryptographic hash function is required.

It's simply a broken protocol. To fix this, IMA must only support
signatures that use the ima_file_id scheme.

Of course, that will require making them support full-file hashes and
not just fsverity hashes. If I recall correctly, this was actually part
of the original design of the ima_file_id-based signatures. It's
unclear why the implementation is still incomplete.

- Eric