On Wed, 2020-08-26 at 18:00 -0700, Eric Biggers wrote:
> On Wed, Aug 26, 2020 at 08:53:33PM -0400, Mimi Zohar wrote:
> > On Wed, 2020-08-26 at 13:51 -0700, Eric Biggers wrote:
> > > Of course, the bytes that are actually signed need to include not just the hash
> > > itself, but also the type of hash algorithm that was used. Else it's ambiguous
> > > what the signer intended to sign.
> > >
> > > Unfortunately, currently EVM appears to sign a raw hash, which means it is
> > > broken, as the hash algorithm is not authenticated. I.e. if the bytes
> > > e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 are signed,
> > > there's no way to prove that the signer meant to sign a SHA-256 hash, as opposed
> > > to, say, a Streebog hash. So that will need to be fixed anyway. While doing
> > > so, you should reserve some fields so that there's also a flag available to
> > > indicate whether the hash is a traditional full file hash or a fs-verity hash.
> >
> > The original EVM HMAC is still sha1, but the newer portable & immutable
> > EVM signature supports different hash algorithms.
> >
>
> Read what I wrote again. I'm talking about the bytes that are actually signed.
I agree including the hash algorithm in the digest would be
preferrable, but it isn't per-se broken. The file signature and the
file metadata hash algorithms are the same, otherwise signature
verification fails[1]. The same tool calculates the file metadata
digest and then signs the digest, using the same hash algorithm. In
terms of the HMAC, it is (still) limited to SHA1.
Mimi
[1] commit 5feeb61183dd ("evm: Allow non-SHA1 digital signatures")
