Re: [gentoo-dev] proposal: use only one hash function in manifest files

[Rich Freeman]

On Tue, Apr 5, 2022 at 8:05 PM Sam James <sam@g.o> wrote:
> > On 5 Apr 2022, at 22:13, Jonas Stein <jstein@g.o> wrote:
> >
> >> In other words, what are we actually getting by having _both_ SHA2-512
> >> and BLAKE2b for every file in every Manifest?
> >
> > Implementations are often broken and we have to expect zero day attacks on hashes and on signatures. Hence it does not hurt to have a second hash.
>
> I don't think this is the case. They're not broken often, it's a very very big deal when they do, and we'd also have far bigger problems in such a case (as already pointed out, TLS would be an issue, but also GPG signatures, git commit hashes, ...).

Our security fails currently if EITHER SHA2-512 or a hardened version
of SHA-1 are defeated.  Our top gpg signature is bound to a git commit
record by SHA2-512, and the git commit record is bound to everything
else in the repository (including the manifest objects) by SHA-1,
because git hasn't transitioned away from that (as far as I'm aware it
is still a work in progress - the SHA-1 algorithm it uses is hardened
against known attacks).

That said, I think there is still an argument for having two hashes in
the manifests.  If we have two independent manifests, then if either
SHA-1 or SHA2-512 are defeated all we need to do is update git+gpg to
the patched version (which no doubt would be rushed into a release
quickly), and then do a commit to the repo and sign it with the Gentoo
key.  The new commit would have a full set of new hashes using a
secure hash function, and then a back-reference to the previous commit
using SHA-1 (assuming we didn't rebase the entire tree and lose all
our historical gpg signatures - we might consider creating a new repo
and saving a historical one).   That would have new hashes all the way
from the top commit down to all the objects it references, so the top
commit would now be secure.  When signed with an updated gpg the
signature would be attached with a secure hash.  So now we're secure
again.  If we're concerned about old signatures getting recycled in
preimage attacks we could of course revoke the key and issue a new
one.

What we don't need to do is redo all the manifests, and that is
important because we don't actually have the ability to redo those
centrally.  Anybody can add a commit to the repo and re-sign it, but
we'd need all the maintainers to go through and generate new manifests
for anything that is fetch-restricted, or aggressively treeclean.

So it isn't that having two hashes can't fail, but rather that if it
does fail it is easier to recover.

>
> >
> > It is very likely that we can not trust in X for a while in the next years, but it is very unlikely that two different implementations are affected.
> >
>
> I don't think it is likely that e.g. SHA512 will be broken in the next few years, no, but if it is going to be, we have far bigger issues and we'd need to have double algorithms in our whole stack, which we don't have.

I agree that this is an unlikely scenario, so it is a judgement call
as to whether the ease of recovery in the event of a failure is worth
the cost to maintain the second hash.  I agree that we'd need double
algorithms in the whole stack to prevent a failure, but in the current
state we do have advantages for recovering from a failure after the
fact.

It seems that the likely scenario is that we get advance warning of
weaknesses in a hash function, but without a practical exploit being
readily available.  In that case we could do a  more orderly
transition.  We'd still save time with the double hashed manifests,
and whether this makes a difference is hard to say.

>
> > Additionally calculating a second hash does not cost anything.
>
> It does have a cost at both Manifest-generation time and emerge-time.

This is certainly true, though if the current algorithm is reading the
files twice we could at least fix that.

I don't really have a strong opinion here.  I just wanted to point out
the recovery benefit of having two hashes on just the manifests, given
that it isn't easy to access all the distfiles.  I also wanted to
point out that we have SHA-1 exposure today, at least in git.

-- 
Rich