{"thread":{"id":"45231","subject":"git-sha-x: idea for stronger cryptographic verification while keeping SHA1 content addresses","startedAt":"2017-02-26T18:18:36Z","lastAt":"2017-02-26T18:18:36Z","messageCount":1,"participants":["Steffen Prohaska"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"312690","messageId":"E030EA10-F755-4154-900A-3FCED3ADD1B2@zib.de","threadId":"45231","inReplyTo":null,"subject":"git-sha-x: idea for stronger cryptographic verification while keeping SHA1 content addresses","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2017-02-26T17:07:00Z","receivedAt":"2017-02-26T18:18:36Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"Hi,\n\nRelated to shattered, the recent discussion,\n, the\npast\n,\nand Linus's post ,\nthe idea below might be interesting.\n\nI skimmed through the discussion but haven't read all the details. I also\nhaven't been following the Git list during the last years, so it might very\nwell be that others have described similar ideas and the general approach has\nbeen reject for some reason that I'm not aware of.\n\ngit-sha-x illustrates a potential solution for stronger cryptographic content\nverification in Git while keeping SHA1 content pointers.\n\ngit-sha-x is available at .\n\ngit-sha-x computes a hash tree similar to the SHA1-based Git history but using\na different hash function. The hashes can be added to the commit message and\nsigned with GPG to confirm the tree and the entire history with a cryptographic\nstrength that no longer depends on SHA1 but on the chosen git-sha-x hash and\nthe GPG configuration. See `git-sha-x --help`. Examples:\n\n```\ngit-sha-x commit HEAD\ngit-sha-x tree HEAD\ngit-sha-x --sha512 commit HEAD\n\ngit-sha-x amend && git-sha-x --sha512 amend && git commit -S --amend -C HEAD\n```\n\ngit-sha-x is only a proof of concept to illustrate the idea. I do not intend\nto develop it further.\n\nIf a similar approach was chosen for Git, the hashes could be managed by Git\nand somehow represented in its object store as supplementary information. Git\ncould incrementally compute additional hashes while it constructs history and\nverify them when transferring data.\n\nThe strength of bare SHA1 ids is obviously not increased. The strength is only\nincreased if the additional hashes are communicated in a verifiable way, too.\nGPG signatures are one way. Another way could be to communicate them via\na secure channel and pass them to git fetch for verification. Assuming such an\nimplementation, a fetch for a commit from this repo could look like:\n\n```bash\ngit fetch origin \\\n --sha256=8a3c72de658a4797e36bb29fc3bdc2a2863c04455a1b394ed9331f11f65ba802 \\\n --sha512=729de81500ce4ad70716d7641a115bd0a67984acc4d674044b25850e36d940bf631f9f6aa881111768743690545ac899888fb54f65840f84853f9a8811aeb9ca \\\n ef2a4b7d216ab79630b9cd17e072a86e57f044fa\n```\n\nFor practical purposes, supplementary hashes in the commit in combination with\nGPG signatures should provide sufficient protection against attackers that try\nto manipulate SHA1s. For convenience, supplementary hashes could be stored in\nthe commit header, similar to `gpgsig`. A hypothetical commit object could\nlook like:\n\n```\ntree 365c7e42fd004a1778c6d79c0437f970397a59b8\nparent c2bfff12099b32425a3bcc4d0c7e6e6a169392d8\ntree-sha256 2f588b9308b5203212d646fb56201608449cb4d83a5ffd6b7e6213d175a8077c\nparent-sha256 090d9a3e69aa3369efac968abde859a6e42d05b631ece6d533765a35e998336c\ntree-sha512 12ae91b23733d52fa2f42b8f0bb5aeaeb111335688f387614c3b108a8cb86fa0e2cd6d19bf050f8a9308f8c1e991080507c91df53e0fc4cace3f746ec89a789a\nparent-sha512 d319889a40cf945d8c61dbe6d816e10badd49845c547df85ace4327676275eeb5ba2cd962712ddbb8f08f2db17dbc9eb46b59b5f7b7a7e05eab7df0ef89dec65\nauthor Steffen Prohaska 1488122961 +0100\ncommitter Steffen Prohaska 1488123452 +0100\ngpgsig ...\n```\n\nGPG signatures would automatically cover the supplementary hashes.\nVerification code paths would have to be added to compute the hashes from the\ncontent to confirm that it has not been tampered with.\n\nSince content verification would become independent from the content address,\nthe interpretation of the content address could be changed in the future. The\nsize of 160 bits could be kept for simplicity. But the meaning could be\nchanged. For example, the first 160 bits of SHA256 could be uses as the\ncontent address. The remaining bits could be stored in an object supplement.\nVerification code paths would combine the content address with the additional\nbits to verify the SHA256. Content pointers would keep their size. Only the\nadditional SHA256 bits would be stored and used for verification.\n\nSteffen\n\n"}]}