On Tue, Apr 5, 2022 at 8:05 PM Sam James <s...@gentoo.org> wrote: > > On 5 Apr 2022, at 22:13, Jonas Stein <jst...@gentoo.org> 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
